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4  DEC  1982 


MEMORANDUM  FOR  UNDER  SECRETARY  OF  DEFENSE  FOR  RESEARCH  AND 

ENGINEERING 

SUBJECT:  Embedded  Computer  Instruction  Set  Architectures 


I  have  reviewed  the  Defense  Science  Board  Task  Force 
Report  on  Embedded  Computer  Resources  and  have  approved 
the  recommendations  contained  in  the  letter  of  the  Defense 
Science  Board  Chairman  that  transmitted  the  report  to  me. 

Accordingly,  please  ensure  that  the  Department's 
implementing  instructions  for  standardizing  embedded 
computer  instruction  set  architectures  (ISA)  contain 
provisions  for  adding  suitable  commercial  ISAs  to  the 
Department's  approved  list — while  maintaining  an  open 
and  equitable  competitive  environment. 
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MEMORANDUM  FOR  SECRETARY  OF  DEFENSE 

THROUGH:  UNDER  SECRETARY  OF  DEFENSE  FOR 

SUBJECT:  Report  o£  Defense  Science  Board 
Computer  Resources  (ECR) 


The  enclosed  final  report  of  the  Defense  Science  Board  Task 
Force  on  Embedded  Computer  Resources  Acquisition  and  Management 
was  prepared  under  the  Chairmanship  of  Dr.  Thomas  H.  Crowley. 
The  Task  Force  was  chartered  to: 

"...review,  evaluate  and  make  recommendations  concerning 
the  acquisition,  management  and  utilization  of  digital 
computers  and  associated  technology  to  support  the  military 
mission  of  the  Department  of  Defense." 

The  scope  of  this  study  does  not  apply  to  all  computers  to  be 
purchased  by  the  Department;  it  applies  only  to  MIL-SPEC 
Computers  which  must  have  a  specially-designed  character  to  meet 
military  needs. 

The  principal  findings  of  the  Task  Force  are  that: 

1.  Embedded  Computer  Instruction  Set  Architectures 

should  be  standardized  on  a  few  select  architectures. 

2.  The  Government  should  have  unlimited  rights  to  the 

Instruction  Set  Architectures  used  so  as  to  guarantee 
that  a  basis  exists  for  competitive  procurements  with 
fair  and  equitable  competition. 

3.  There  is  no  consistent  management  approach  across  the 
OSD  Staff  and  the  Military  Departments  relating  to 
computer  technology. 

4.  The  AdaR  Computer  language  program  is  sound,  is 

clearly  a  step  in  the  right  direction,  and  should 
continue  to  be  implemented. 
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Specific  recommendations  are  nade  by  the  Teak  Force  to  address 
these  and  other  critical  areas.  Action  has  already  been  taken 
to  centralise  coaputer  acquisition  nanagenent  within  the  Office 
of  the  Under  Secretary  of  Defense  for  Research  and  Engineering. 
X  understand  that  plans  are  also  being  Bade  to  strengthen  the 
Technology  Base  activities  in  this  inportant  area  and  that  these 
two  activities  will  be  very  closely  coordinated.  This  will  be  a 
aajor  step  toward  iapleaenting  the  recoaaendations  of  this  study 
and  of  the  DSB  1981  Suaaer  Studies  on  the  Technology  Base  and  on 
Operational  Readiness. 

I  recoaaend  that  you: 

1.  Review  the  Executive  Sunnary. 

2.  Approve  distribution  of  the  report. 

3.  Ask  the  Under  Secretary  of  Defense  for  Research  and 
Engineering  to  add  suitable  commercial  Instruction 
Set  Architectures  to  the  Departaent's  approval  list — 
while  aaintaining  an  open  and  equitable  coapetitive 
environment.  (Memo  attached  for  your  signature.) 

In  ay  view,  this  report  provides  insight  into  issues  which  are 
critical  to  the  coabat  and  cost  effectiveness  of  aany  of  our 
nost  complex  weapon  systeas.  As  you  know,  the  efforts  of  this 
Task  Force  have  received  considerable  scrutiny  in  recent  aonths. 
The  subject  natter  at  hand  is  inherently  subject  to  soae  degree 
of  disagreeaent  anong  competent  and  honest  investigators.  The 
interests  of  the  Departaent  will  be  best  served,  in  ay  judgment, 
by  asking  this  report  available  to  the  public  so  that  it  night 
be  scrutinised  openly  and  its  findings  weighed  in  an  appropriate 
Banner. 


Rormaii  R*  Augustine 
Chairman 

Attachment t 
BCR  Report 


Copy  to: 
DepSecDef 
Chairman,  JC8 
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1  November  1 982 


RESEARCH  ANO 
ENGINEERING 

MEMORANDUM  FOR  THE  CHAIRMAN,  DEFENSE  SCIENCE  BOARD 


SUBJECT:  Final  Report  of  the  Task  Force  on  Embedded  Computer  Resources 
(ECR)  Acquisition  and  Management 


Enclosed  is  the  final  report  of  the  Defense  Science  Board  Task  Force  on 
Embedded  rnmpnter_Jj;e sources  (ECR)  Acquisition  and  Management f  It  treats  all 
(St  the  quest ionsasked  by  Dr.  DeLauer  in  his  request  of  August  20,  1981.  As 
[you  are  aware,  the  full  Defense  Science  Board  was  briefed  on  the  6tudy  and  was 
[presented  the  Findings  and  Recommendations  on  February  10,  1982. 


Most  of  our  attention  was  absorbed  by  the  question  of  whether  the  Department 
should  adopt  a  policy  of  standardizing  the  so-called  Instruction  Set 
Architectures  (ISAs)  of  militarized  computers.  This  issue  has  been  hotly 
debated  in  many  forums  and  was  a  principal  motivation  for  the  establishment  of 
the  Task  Force.  Much  of  the  controversy  here  is  because  of  the  natural 
differences  between  producers  and  consumers.  He  looked  very  carefully  at  the 
needs  and  points  of  view  of  both  sides  of  this  question.  Our  conclusion  is 
that  the  needs  of  the  Department  for  battlefield  survivability  and 
sustainability  are  paramount.  We  found  that  limiting  ISA  choices  to  a  few  is 
a  big  help  in  meeting  those  needs.  Individual  companies  do  precisely  this  for 
economic  reasons;  DoD  must  adopt  this  approach  if  there  is  to  be  any 
possibility  of  capping  the  exploding  logistics  and  software  costs.  Language 
standardization  is  not  sufficient  by  itself,  as  many  claim.  We  recommend  that 
proposed  DoD  Instruction  5000. Sx  be  Issued  immediately.  There  are  programs 
under  way  in  each  of  the  Military  Departments  which  Implement  5000. 5x.  We 
recommend  that  those  programs  proceed  with  some  relatively  minor  changes. 


We  firmly  support  the  Ada*  program.  There  is  almost  universal  agreement  that 
this  program  is  sound  in  objective  and  action.  Specific  recommendations  are 
offered  to  strengthen  some  areas  and  to  assure  its  continued  support,  but,  by 
and  large,  it  is  proceeding  in  the  right  direction. 

We  make  both  specific  and  general  recommendations  on  OSD's  management  of  the 
acquisition  and  management  of  computers  and  related  digital  technology.  More 
centralization  of  policy  and  oversight  is  needed  and  we  note  that  action  is 
already  under  way  to  improve  this  situation. 


Our  detailed  Findings  and  Recommendations  are  summarized  in  the  Executive 
Summary  (Chapter  1)  of  the  attached  Report. 
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Finally,  I  wish  to  express  my  appreciation  for  the  fine  work  and  dedication  of 
the  Task  Farce  and  to  those  in  the  Department,  the  Services  and  in  Industry 
who  supported  us. 


Thomas  H.  Crowley 
Chairman 

DSB  Task  Force  on  ECR 
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FOREWORD 


The  significance  of  the  use  of  computers  in  defense  systems  has  grown 
explosively  over  the  past  decade.  Costs  associated  with  this  phenomenon  have 
also  Increased  exponentially.  The  Electronic  Industries  Association  in  their 
"DoD  Digital  Data  Processing  Study,  a  Ten-Year  Forecast,"  completed  late  in 
1980  predicted  that  DoD's  Investment  in  embedded  computer  hardware  and 
software  would  increase  from  approximately  $4.1  Billion  in  1980  to  almost  $38 
Billion  in  1990. 

Various  measures  have  been  taken  to  control  this  rapid  increase  in 
Investment  while  increasing  the  effectiveness  of  defense  systems  through 
better  and  more  extensive  automation.  Still  other  measures,  such  as 
standardizing  the  Instruction  Set  Architectures  for  militarized  computers, 
have  been  proposed.  These  policy  initiatives  have  met  with  varying  degrees  of 
acceptance  in  the  Department  of  Defense  and  in  Industry.  In  August,  1981,  the 
Under  Secretary  of  Defense,  Research  and  Engineering  asked  the  Defense  Science 
Board  to: 

"...review,  evaluate  and  make  recommendations  concerning  the 
acquisition,  management  and  utilization  of  digital  computers  and 
associated  technology  to  support  the  military  mission  of  the 
Department  of  Defense." 

This  is  the  Final  Report  of  the  Task  Force  on  Embedded  Computer  Resources 
(ECR)  Acquisition  and  Management  which  was  formed  in  response  to  that  request. 

Chapter  1  is  the  Executive  Summary  which  describes  the  Scope  and 
Objectives  of  the  study  and  the  approach  which  was  taken.  The  major  findings 
and  recommendations  are  then  given  with  the  recommendations  listed  in 
"priority"  order. 

The  Background  which  led  up  to  the  formation  of  the  Task  Force  is 
discussed  in  Chapter  2.  Chapter  3  provides  a  description  of  key  programs 
within  the  Components  of  DoD  which  attack  the  problems  of  costs  and  other 
critical  problems  associated  with  Increased  reliance  on  computers  in  mission 
systems.  Chapter  4  gives  a  general  perspective  on  standardization  —  an 
important  mechanism  for  management  of  computers  and  software  —  and  discusses 
the  possibilities  of  a  High  level  Language  (HLL)  machine  for  future 
applications.  A  thorough  treatment  of  the  issues  surrounding  proprietary  data 
rights  is  presented  in  Section  4.3  beginning  on  page  32.  This  area  was  found 
by  the  Task  Force  to  be  one  of  the  most  difficult  to  handle  in  the  decision  of 
whether  to  base  standardization  only  on  Government-owned  intellectual  property 
or  whether  there  is  an  equitable  way  in  which  proprietary  designs  may  be 
Included . 

In  Chapter  5  ws  discuss  the  major  issues  posed  in  the  Charter  for  the 
Task  Force  with  concentration  on  whether  the  proposed  DoD  Instruction  5000. 5x 
concerning  Instruction  8et  Architecture  (ISA)  standardization  should  be 
issued.  We  also  Include,  in  Section  5.2,  recommendations  relative  to  the 


existing  Service  programs  which  Implement  the  intent  of  5000. 5x.  Section  5.3 
discusses  DoD's  High  Order  Language  (HOL)  standardisation  program;  Section  5.4 
contains  reconmendations  on  the  near-term  use  of  Ada*  and  hardware  from  the 
Military  Computer  Family  project  in  the  upgrade  of  the  World-Wide  Military 
Command  and  Control  System  (WWMCCS).  Sections  5.5  and  5.6  contain 
recommendations  on  overall  DoD  policy  and  on  the  management  and  oversight 
process.  Section  5.7  discusses  the  implementation  of  recent  legislative 
changes  (10.  U.S.C.  2315). 

Appendix  C  contains  a  set  of  recommended  definitions  for  the  specialized 
terms  used  ^n  the  embedded  or  mission-critical  computer  arena.  The  Task  Force 
recommends  that  these  definitions  be  adopted  for  DoD- wide  use. 

We  wish  to  thank  Mr.  Norman  V.  Brown,  a  patent  attorney  assigned  to  the 
Naval  Sea  Systems  Command,  for  his  valuable  contributions  to  the  discussion  of 
rights  in  data  (Section  4.3).  Special  commendation  is  due  Mrs.  Jo  Ingram, 
OUSD(R&E)ECR,  for  her  outstanding  administrative  support  of  the  Task  Force  and 
to  Messrs.  Miguel  Hornedo,  OUSD(RAE)  And  Burt  Newlin  of  the  Defense  Materiel 
Specifications  and  Standards  Office  for  their  excellent  staff  support  and 
preparation  of  the  meeting  minutes. 
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1.  EXECUTIVE  SUMMARY 


1.1  Scope  and  Objectives 

The  basic  direction  and  guidance  to  the  Task  Force  was  contained  in  a 
memorandum  dated  August  20,  1981,  from  Dr.  Richard  D.  DeLauer,  Under  Secretary 
of  Defense  for  Research  and  Engineering.  This  Memorandum  is  included  as 
Appendix  A.  The  Task  Force  was  asked  to: 


"...review,  evaluate  and  make  recommendations  concerning  the 
acquisition,  management  and  utilization  of  digital  computers  and 
associated  technology  to  support  the  military  mission  of  the 
Department  of  Defense." 


More  specifically,  Dr.  DeLauer  posed  the  following  key  questions: 


-  Are  current  and  proposed  management  policies  appropriate? 

-  Are  key  embedded  computer  resource  programs  properly  constituted  and 
supported? 

-  Are  Management  and  Oversight  adequate? 

-  What  is  the  effect  of  the  Legislative  and  Regulatory  Environment? 


1 .2  Approach 

Task  Force  members  were  selected  to  provide  a  wide  variety  of  views  on 
the  topic  of  computer- related  research  and  development,  acquisition  and 
utilization.  A  balance  of  producers,  system  integrators,  academicians  and 
Military  representatives  was  sought.  Several  of  the  members  had  previous 
experience  in  senior  level  government  positions.  Mr.  William  A.  Long,  Deputy 
Under  Secretary  of  Defense,  Acquisition  Management,  was  the  Task  Force 
Sponsor.  Dr.  Thomas  H.  Crowley,  Bell  Laboratories,  served  as  Chairman. 
Appendix  B  lists  the  members  and  staff  of  the  Task  Force. 


Briefings  were  received  from  both  Government  and  Industry.  In  addition, 
a  request  for  information  was  published  in  the  Commerce  Business  Daily  which 
elicited  20  detailed  responses. 


The  Task  Force  met  four  times  in  the  Washington,  DC  area.  In  addition,  a 
subgroup  met  on  the  West  Coast  and  a  team  visited  the  Army  Communication  and 
Electronics  Command  (CECOM)  at  Ft.  Monmouth,  NJ  to  gather  more  detail  on  the 
Army’s  Military  Computer  Family  Project  which  was  of  major  interest. 


1.3  Major  Issues 


The  Task  Force  Identified  the  following  seven  major  issues: 


1.  Should  DoD's  proposed  policy  to  standardize  on  a  small  set  of 
Instruction  Set  Architectures  (ISAs)  be  issued? 

2.  Are  the  Service  programs  which  implement  this  proposed  policy 
reasonable? 


3.  Should  the  DoD's  program  to  provide  a  common  language  for  broad  use 
across  the  Department  —  the  Ada®»^  Program  —  be  modified? 


4.  Should  Ada*  and  the  Military  Computer  Family  (MCF)  be  used  for  the 
World  Wide  Military  Command  and  Control  System  (WWMCCS)  Information 
System  (WIS)  upgrade? 


5.  Are  changes  needed  in  DoD  Directive  5000.29,  "Management  of 
Computer  Resources  in  Major  Systems?" 

6.  Are  changes  desirable  to  management  of  DoD's  computer  acquisition 
and  management  policies? 

7.  Should  the  acquisition  process  itself  be  modified? 


1 .4  Major  Findings 

Major  findings  are: 


1.  The  controversy  over  proposed  DoD  Instruction  5000. 5x  is  largely 
between  interests  which  have  as  primary  concerns  the  marketing  and 
procurement  of  military  embedded  computers  and  interests  which  have 
as  primary  concerns  the  operation,  maintenance,  deployment  and 
post-acquisition  support  of  these  same  computers.  Both  sides  often 
neglect  complex  issues  inherent  in  these  concerns.  The  situation 
is  further  complicated  by  the  fact  that  procurement  issues  are 
immediate  and  precisely  measurable  in  dollars  soon,  while  providing 
a  cost-effective  deployment  and  support  environment  for  the  rest  of 
the  century  is  longer  range  and  harder  to  quantify.  In  other 
words,  the  time-frame  foci  of  the  two  sides  in  this  controversy  are 
quite  different.  Arguments  are  further  confused  over  the 
questions: 


a.  "Should  there  be  a  standard  set  of  ISAs  at  all?” 


*Ada  Is  a  registered  Trademark  of  the  U.S.  Department  of  Defense  (Ada  Joint 
Program  Office) 
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b.  "If  there  are  to  be  standards,  should  they  be  Government- 
cmmed  or  Commercial  ones?" 

2.  Embedded  Computer  Instruction  Set  Architectures  (ISAs)  should  be 
standardized.  This  action  is  necessary  if  the  Department  of 
Defense  is  to  improve  its  position  with  respect  to  software 
development  costs  and,  further,  it  is  a  mandatory  step  toward 
improvement  of  the  logistic  support  and,  above  all,  the  battlefield 
sustainability  of  automated  systems . 

3.  Given  our  finding  of  support  for  ISA  standardization.  Government 
control  over  the  ZSAs  is  required.  It  is  unwise  to  commit  for  an 
extended  period  to  an  ISA  which  can  be  changed  or  differently 
supported  in  the  interests  of  a  commercial  entity.  Too  many 
considerations  of  competitive  follow-on  procurement,  overseas 
manufacture  and  ongoing  support  are  at  stake.  There  may  yet  be  an 
acceptable  approach  for  including  "commercial  ISAs”  on  the  DoD- 
approved  list  while  maintaining  an  open  and  equitable  competitive 
environment.  Past  failures  should  not  dissuade  OSD  from  continued 
efforts  toward  this  objective.  ISA  Standardization  will  affect 
competition  for  hardware  procurements  and  the  effect  may  be  either 
positive  or  negative  in  specific  cases.  With  standardization  on  a 
"good"  set  of  government-owned  ISAs,  Industry  has  the  opportunity 
to  enter  competition  on  an  equal  basis. 

4.  It  is  important  that  implementation  of  the  standardization  policy 
for  ISAs  be  actively  managed  from  the  OSD  level  —  particularly  the 
waiver  process  —  to  assure  that  Service  conformance  is  neither 
cavalier  nor  slavish.  Carefully  done,  the  policy  could  facilitate 
the  introduction  of  technology;  carelessly  done  it  could 
significantly  impede  progress. 

5.  Current  Service  programs  based  on  ISA  standardization  are  in  accord 
with  general  policy  intent;  there  are,  however,  areas  wherein  they 
could  be  strengthened.  Ihe  issue  of  multiple  producers  for 
logistically-identical  hardware  is  still  an  open  question  and  one 
which  deserves  more  study. 

6.  No  formal  program  exists  to  bring  the  long-term  ISAs  of  the 
Services  together.  This  convergence  could  be  a  great  step  towards 
promoting  Joint  Task  Force  (JTF)  interoperability  as  well  as  other 
capabilities  for  combined  interservice  operations.  An  important 
chance  to  nudge  the  Services  together  now  exists.  The  Air  Force  is 
monitoring  and  participating  in  the  Army's  NEBULA  program.  Air 
Force  adoption  of  NEBULA  represents  a  one-time  opportunity  to 
accomplish  convergence  between  the  two  Services  who  operationally 
need  it  most. 


N 


2 

Cf . ,  Section  4. 3. 2. 3,  page  35. 


7.  High  Order  Language  (HOL)  standardization  has  had  a  positive  effect 
on  software  development  and  support  costs.  Implementation  of  the 
policy  to  use  HOLs  has,  however,  been  spotty. 

8.  DoD's  Ada*  Program  is  well  based  and,  in  general,  is  proceeding 
satisfactorily.  It  could,  however,  be  improved  through  better  DoD- 
wide  coordination.  The  Ada  Language  System  (ALS)  does  not  appear 
to  be  receiving  adequate  attention  in  view  of  its  criticality  to 
the  MCF  Program  and  to  efforts  of  the  other  Services.  Both  the 
Navy  and  the  Air  Force  could  accelerate  the  availability  of  Ada  for 
their  specific  use  with  modest  additional  investments. 

9.  A  large  quantity  of  existing  software  —  some  10  to  15  million 
lines  of  code  —  must  be  preserved  in  the  WWMCCS  Information  System 
(WIS).  There  will  be  some  two  to  three  million  lines  of  code 
added,  as  currently  estimated.  The  schedules  for  the  upgrade 
generally  precede  the  availability  of  either  Ada  or  MCF.  However, 
it  appears  to  us  that  use  of  Ada  as  a  Program  Design  Language  (PDL ) 
is  desirable  and  that  its  structure  and  discipline  have  much  to 
offer  in  such  a  major  undertaking  as  the  WIS  upgrade. 

10.  DoD  Directive  5000.29  is  the  basic  policy  document  for  automated 
defense  systems  and  its  revision  and  update  are  urgent  matters  for 
action.  Problems  still  exist  with  regard  to  computers  and  software 
and  it  is  too  early  to  force  this  area  into  the  routine  oversight 
pattern  afforded  to  more  mature  technologies.  Work  is  needed  to 
rationalize  DoD's  inconsistent  set  of  specifications  and  standards 
for  computer  resources.  Further,  recent  legislative  changes  must 
be  promulgated  and  5000.29  is  a  proper  vehicle  for  this. 

1 1 .  There  is  no  consistent  management  process  across  the  OSD  Staff  and 
the  Military  Departments  relating  to  computer  (automation) 
technology.  OSD  has  been  relying  on  a  committee  management 
approach  which  was  born  of  necessity  in  1976.  The  scope  of 
automation  in  systems  and  in  their  support  has  far  outstripped  this 
approach. 

12.  Although  the  legislative  initiative  of  the  Senate  Armed  Services 
Committee  to  separate  DoD's  acquisition  of  computers  from  the 
Brooks  Act  process  is  an  important  step  forward,  we  found  that 
there  is  yet  confusion  as  to  how  this  change  should  be  implemented. 
Logistics  systems  are  particularly  a  source  of  concern  as  they 
still  fall  in  the  gray  area  between  two  acquisition  approaches. 
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1.5  Recommendations 
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We  recommend  that: 


I 


»*' 


1.  The  proposed  DoD  Instruction  5000. 5x  be  issued.  It  should  be 
reviewed  for  consistency  with  acquisition  regulations  and  the  scope 
should  be  clarified,  e.g.,  where  does  it  apply  and  where  does  it 
not.  OSD  should  actively  manage  implementation  of  the  policy  and 
control  both  the  waiver  process  and  changes  to  the  approved  ISA 
list. 

2.  The  Military  Departments  proceed  with  current  programs  —  the  Army 
Military  Computer  Family  (MCF) ,  the  Navy  Tactical  Embedded  Computer 
Resources  (TECR)  Program  and  the  Air  Force  MIL-STD-1750  Program 

—  but  with  some  modifications: 


a.  The  Army  increase  the  quantity  of  Advanced  Development  Models 
(ADMs)  and/or  Full  Scale  Development  Models  (FSDMs)  of  the 
MCF  hardware  to  provide  and  support  early  software 
development  experience. 

b.  Both  the  Army  and  Navy  revise  their  acquisition  strategies  to 
make  use  of  multiple  producers  of  logistically-identical 
computer  hardware,  if  economically  feasible. 

c.  The  Air  Force  bound  the  number  of  unique  Implementations  of 
MIL-STD-1750  with  an  eye  toward  achieving  logistic  cost 
avoidance. 

d.  The  Air  Force  consider  adding  Input/Output  specifications  and 
other  hardware-independent  details  to  MIL-STD-1750. 

e.  Army  and  Air  Force  develop  an  implementation  plan  for  their 
Memorandum  of  Agreement  covering  joint  adoption  and  use  of 
MIL-STD-1862.  This  plan  should  be  subject  to  OSD  review  and 
approval . 

f.  The  three  Military  Departments,  J.n  conjunction  with  OSD, 
develop  an  approach  and  plan  for  joint  action  toward  a  truly 
common  architecture  much  as  was  done  for  the  common  language, 
Ada.  The  activities  of  the  preceding  paragraph  should  form  a 
basis  for  this  recommended  action. 

3.  Designate  a  Senior  Policy  Official  (USDRE)  for  10  U.S.C.  2315 
matters  and  establish  a  consistent  management  approach  across  the 
OSD  staff  and  within  the  Military  Departments.  The  first  action 
has  been  taken  concurrently  with  our  deliberations  and  preparation 
of  this  report.  The  Under  Secretary  should  now: 


a.  Determine  the  level  and  mode  of  operation  and  provide  revised 
guidance  to  the  Components  regarding  implementation  of  P.L. 
97-86  (codified  as  10  U.S.C  2315). 


J>.  Establish  a  uniform  set  of  R&D  objectives  and  acquisition 
policies  which  are  mutually  supportive. 

c.  Provide  OSD  management  of  selected  generic  automation 
programs,  such  as  has  been  done  for  Ada  and  the  Very  High 
Speed  Integrated  Circuits  (VHSIC)  Program. 

d.  Task  tiie  official  to  whom  this  new  policy  designation  is 
delegated  to  be  a  principal  advisor  to  the  Defense  Systems 
Acquisition  Review  Council  (DSARC)  on  computer  and  software 
(automation)  matters. 

e.  Improve  OSD's  oversight  of  Components'  computer  and  software 
R&D  and  acquisition  activities. 

4.  DoD  Directive  5000.29  be  revised  expeditiously.  Incorporate 
changes  in  acquisition  approach  enabled  by  10  United  States  Code 
2315.  Emphasize  the  “ software-first”  approach  to  system  design  and 
development  and  encourage  use  of  rapid  software  prototyping  and 
competitive  concept  definition.  Source  selection  procedures  should 
specifically  Include  software  considerations  (this  may  require  DAR 
revisions) . 

5.  DoD  Instruction  5000.31  be  updated  quickly  to  remove  outdated 
languages  and  to  add  Ada. 

6.  The  Under  Secretary  assure  adequate  and  continuing  support  for  the 
Ada  Joint  Program  Office.  (We  note  that  his  statement  to  the 
Congress3  contains  specific  mention  of  the  Ada  Program.) 

7.  The  Service  Ada  Programs  be  strongly  supported  and  that  they 
continue  to  receive  adequate  staff  and  funds.  Components  of  this 
Program  should  be  better  coordinated. 

8.  DoD  develop  and  apply  a  consistent  Bet  of  computer  hardware  and 
software  specifications  and  standards  across  the  Department. 

Current  work  by  the  Joint  Logistics  Commanders  Joint  Policy 
Coordination  Group  for  Computer  Resource  Management  (JPCG-CRM)  may 
be  an  adequate  basis  but  DoD  should  assure  uniform  implementation 
of  the  resulting  product,  whatever  its  genesis4. 

9.  Intersystem  and  local  network  protocols  be  developed  from  existing 
DoD  standards  and  emerging  International  standards.  Standards  for 
data  elements  should  also  be  developed. 


3 The  FT  1983  Department  of  Defense  Program  for  Research,  Development,  and 
Acquisition. 

4 The  Embedded  Computer  Resources  Area  Standardization  Plan  describes  the 
scope  of  this  needed  activity. 


10.  OSD  review  the  opportunities  for  cost  savings  within  the  Air  Force 
JOVIAL  language  program  and  that  the  Air  Force  be  encouraged  to 
strengthen  this  interim  standardization  program  to  achieve 
increased  return  on  Investment. 

11.  OSD  conduct  a  careful  review  of  the  Defense  Acquisition  Regulations 
(DARs)  to  assure  that  they  are  in  step  with  computer  acquisition 
policy.  In  particular,  care  should  be  taken  that  time  limitations 
in  the  DARs  do  not  drive  technology  insertion  schedules  through 
misinterpretation.  The  DARs  must  not  attenuate  sharing  of 
government-developed  applications  or  support  software. 

12.  The  WIS  Joint  Program  manager  adopt  Ada  into  the  WIS  language 
family  as  soon  as  its  stability  is  assured  and  support  software  of 
adequate  performance  and  maturity  is  available.  It  is  estimated 
that  this  will  occur  in  the  1984-1985  time  period.  We  also 
recommend  that  WIS  use  Ada  now  as  a  Program  Design  Language  when 
acquiring  parts  of  the  system  which  involve  major  software 
development . 

13.  The  confusing  technical  and  management  terminology  which  abounds 
should  be  clarified  immediately.  A  glossary  of  key  terms  should  be 
published  and  widely  distributed  and  the  usage  should  be  stabilized 
for  a  rational  period,  say  five  years.  Appendix  C  contains  a 
recommended  set  of  terms  and  definitions. 
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2.  BACKGROUND 


2.1  Policy  Evolution 

Computer  technology  and  its  application  are  critical  to  the  Department  of 
Defense.  Almost  without  exception,  important  systems  used  in  the  conduct  of 
the  mission  of  the  Department  depend  on  computation  and  information 
processing,  communications,  display  and  other  computer  based  processes.  In 
fact,  the  integration  of  defense  systems  processes  and  actions  is  actually 
carried  out  more  in  the  information  domain  than  it  is  in  the  physical  realm. 

In  the  mid-1970s,  the  Department  came  to  the  stark  realization  that  the 
costs  associated  with  computer  applications  to  weapons  and  other  defense 
systems  were  growing  at  a  startling  rate.  A  study  conducted  in  19745 
concluded  that  the  costs  of  software  to  the  Department  of  Defense  for  Fiscal 
Year  1973  were  in  the  range  of  $2.9  to  3.6  Billion. 

With  the  growing  dependence  on  computers  and  software  in  both  major  and 
non-major  systems,  it  was  decided  that  special  management  attention  was 
necessary  at  all  levels  of  the  Department  and  its  Components  (Office  of  the 
Secretary  of  Defense  (OSD),  the  Military  Departments,  the  Organization  of  the 
Joint  Chiefs  of  Staff  (OJCS)  and  the  Defense  Agencies).  A  series  of  policy 
initiatives  were  undertaken: 

-  A  DoD  Defense  System  Software  Management  Plan  was  generated  in 
August,  1975. 

-  A  Statement  of  Policy6  was  drafted  in  October,  1975  and  subsequently 
signed  by  the  Secretary  of  Defense  in  November,  1976. 

7 

-  An  interim  list  of  approved  High-Order  Languages  was  established  • 

o 

-  A  policy  .  of  standardizing  on  a  few  Instruction  Set  Architectures 
was  proposed. 


3Fisher,  David  A.,  "Automatic  Data  Processing  Costs  in  the  Defense 
Department"  Institute  for  Defense  Analyses  Paper  P-1046,  October,  1974 

6DoD  Directive  5000.29,  Management  of  Computer  Resources  in  Major  Defense 
Systems,  November  1976. 

7DoD  Instruction  5000.31 ,  interim  List  of  DoD -Approved  High  Order 
Programs ling  Languages  (HOL) ,  November  24,  1976 


®Draft  DoD  Instruction  5000. xx,  interim  List  of  DoD  Approved 
Architectures,  March  10,  1978 
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The  objective  of  DoDD  5000.29  is  to  assure  that  computer  resources  are 
treated  as  important  subsystems  throughout  the  development,  acquisition  and 
support  phases  of  the  life  cycle  of  defense  systems.  Since  the  nature  of  this 
application  of  computer  technology  goes  beyond  the  functioning  of  the  computer 
as  a  stand-alone  item,  the  term  "embedded"  was  coined  to  differentiate  from 
the  term  "ADPE"  generally  used  to  apply  to  common,  commercial,  off-the-shelf 
products.  ADPE  was  growing  to  be  thought  of,  principally,  for  business  and 
financial  management  applications  and,  under  the  provisions  of  the  Brooks  Act, 
P.L.  89-306,  it  was  a  commodity  subject  to  a  special  acquisition  and 
management  process  outside  the  major  system  acquisition  process. 

DoD  Directive  5000.29  provided  policy  guidance  in  seven  main  areas: 

1 .  Software  Requirements  and  Risk  Analysis 

2.  Software  Configuration  Management 

3.  Computer  Resource  Acquisition  Planning 

4.  Support  Software  Deliverables 

5.  Milestone  Definition  and  Demonstration  Criteria 

6.  Software  Language  Standardization  and  Control 

7.  Coordinated  Research  and  Development 

A  major  mandate  of  the  Directive  was  that  defense  systems  software  be 
developed  in  a  High  Order  Language  (HOL)  and,  further,  that  the  choice  of 
language  was  to  be  from  a  DoD-approved  list.  The  rationale  for  this  degree  of 
detail  was  that  the  costs  associated  with  software  were  growing  rapidly  and 
the  application  of  modern  software  development  techniques  was  seen  as 
potentially  effective  to  stem  this  growth.  It  was  well  recognized  that  the 
efficiency  of  the  software  development  process  could  be  improved  through  the 
use  of  HOLs  and  that  the  possibilities  for  reuse  and  the  ease  of  post 
deployment  supportability  would  be  improved9  ,10. 


Q 

DoD  Weapons  Systems  Sof tware  Acquisition  and  Management  Study,  MITRE 
Technical  Report  6908,  May  1975. 

10PoO  Weapon  Systems  Software  Management  S tudy ,  Applied  Physics  Laboratory, 
The  Johns  Hopkins  University,  Special  Report  75-3E,  June  1975 


The  interim  list  contained  seven  languages  which  were  in  common  use 
within  the  Department  and  hence  languages  for  which  a  support  commitment  had 
been  made  or  was  planned.  Those  languages  were: 

-  CMS -2 

-  SPL-1 

-  TACPOL11 

-  JOVIAL  J-3B 

-  JOVIAL  J-73/I12 

-  COBOL 

-  FORTRAN 

The  more  general  policy  of  moving  to  the  minimum  essential  number  of  such 
approved  languages  was  established  and  the  search  for  a  single  language  which 
would  serve  the  broadest  spectrum  of  DoD  applications  was  undertaken.  This 
activity  has  become  the  Ada9  Program  managed  by  the  Ada  Joint  Program  Office 
(AJPO)  within  the  Office  of  the  Deputy  Under  Secretary  of  Defense  (Acquisition 
Management).  The  objective  of  the  Ada  Program  is: 

"To  develop  a  single  high  order  language  for  writing  software  for 
DoD  embedded  computer  (real  time)  applications.” 

Quoting  from  the  Charter  for  the  AJPO: 

"[Its]  objective  is  to  provide  for  management  of  the  total 
Department  of  Defense  effort  to  Implement ,  introduce  and  provide  life 
cycle  support  for  Ada,  the  DoD  conaon.  High  Order  Programming  Language 
for  embedded  computers.  Ada  is  to  be  a  DoD-wlde  standard  which  will 
enhance  software  portability  and  afford  the  maximum  commonality  of 
tools  (environment)  needed  to  develop  and  support  defense  systems 
software.  The  Ada  Joint  Program  Office  shall  assure  that  validated 
Ada  compilers  and  the  associated  software  development  and  support 
environments  are  available  to  support  a  policy  of  using  only 
accredited  support  software  on  DOD  programs.” 

The  Ada  Program  is  described  more  fully  in  Section  3.1. 


**The  Army  has  subsequently  asked  that  TACPOL  be  dropped  from  DoDI  5000.31. 

*2The  Air  Force  has  replaced  J3-B  and  J73/I  with  JOVIAL- J73  as  described  in 
MIL-STD-1589B. 
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Although  use  of  an  HOL  in  the  development  of  software  and  standardizing 
on  a  minima  number  of  HOLs  are  a  considerable  help  in  reducing  cost  and 
improving  the  overall  process,  there  is  still  required  a  considerable 
specialization  of  the  development  environment.  It  must  be  tailored  to  the 
specific  host/ target  combinations  of  interest.  Thus,  reusability  and 
portability  of  both  support  tools  and  applications  programs  are  attenuated. 

For  these  and  other  reasons,  consideration  has  been  given  to  reducing  the 
number  of  unique  environments  within  which  HOL-based  applications  programs 
must  run.  This  can  be  done  by  controlling  the  interface  between  software  and 
the  target  environment,  i.e.  the  Instruction  Set  Architecture  (ISA)  of  the 
target  machines.  The  definition  of  this  interface  was  taken  to  be: 

"INSTRUCTION  SET  ARCHITECTURE  (ISA) .  The  attributes  of  a  digital 
computer  or  processor  as  might  be  seen  by  a  machine  (assembly) 
language  programmer,  i.e.,  the  conceptual  structure  and  functional 
behavior  as  distinct  from  the  organization  of  the  data  flow  and 
controls,  logic  design,  and  physical  implementation. 


"This  definition  Includes  the  processor  and  Input/output 
instruction  sets,  their  formats,  operation  codes,  and  addressing 
modes;  the  memory  management  and  partitioning  if  accessible  to  the 
machine  language  programmer;  the  speed  of  accessible  clocks;  the 
interrupt  structure;  and  the  manner  of  use  and  format  of  all  registers 
and  memory  locations  that  may  be  directly  manipulated  or  tested  my  a 
machine  language  program. 

"This  definition  excludes  the  time  or  speed  of  any  operation,  the 
internal  computer  partitioning,  the  electrical  and  physical 
organization,  the  circuits  and  components,  the  manufacturing 
technology,  the  memory  organization,  the  memory  cycle  time,  and  the 
memory  bus  widths*-*.” 


E 


1 4 

Instruction 


Standardization  at  the  ISA  level  is  the  basis  of  a  Proposed  DoD 

The  present  version  of  the  proposed  policy  evolved  after  some 
two  years  of  study  and  review.  In  March,  1978  an  earlier  version  of  the 
policy  was  circulated  within  the  OSD  Staff  Elements,  the  Components  and  to  the 
major  affected  industry  associations.  Consensus  was  not  achieved  and  the 


*3Computer  Resources  and  the  DSARC  Process — A  Guidebook.  U.S.  Department  of 
Defense,  April  31,  1981.  The  definition  was  generated  by  the  Instruction  Set 
Architecture  Panel  and  Included  in  their  report  of  March  26,  1980. 


**DoD  Instruction  5000. 5x,  Instruction  Set  Architecture  (ISA) 
Standardisation  Policy  for  Embedded  Computers ,  Draft  December  24,  1980. 
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Instruction  was  not  Issued.  An  Interim  policy*^  was,  however,  developed. 
That  memo  recognised  that  the  unbounded  proliferation  of  ISAs  was  causing 
problems  with  respect  to  continued  growth  of  software  costs  associated  with 
defense  systems.  It  directed  that  a  working  group  be  formed  to  study  this 
issue  and  to  recommend  a  course  of  action.  Further  policy  guidance  was 
provided  in  a  subsequent  memorandum*^: 

"It  is  the  Intent  of  DoD  Instruction  5000. 5x,  in  addition  to 
preventing  unwarranted  hardware  proliferation  and  facilitating 
software  development  and  support,  to  assure  that  all  embedded  computer 
acquisitions  can  and  are  accomplished  in  a  meaningfully  competitive 
manner.  DoD  Instruction  5000. 5x  has  always  been  predicated  upon 
government  ownership,  or  appropriate  license  for  government  use,  of 
architectures  on  the  list.  No  architecture  claimed  to  be  proprietary 
shall  be  included  on  the  list  unless  valid  license  agreement  is  in 
force  and  effect  at  the  time  the  architecture  is  included.  [Emphasis 
added  .1  ™ 


"The  Army  Military  Computer  Family  (MCF)  Program  is  an  important 
developmental  approach  toward  achieving  vendor  independence  with 
respect  to  embedded  computer  architectures  and,  as  such,  is  fully 
supported  by  OSD.  He  support  the  Army' 6  position  that  standardization 
is  an  essential  element  in  their  efforts  to  automate  the  battlefield 
in  the  '80s  and  beyond  and  to  achieve  the  meaningful  competition 
mandated  by  the  Congress." 


The  recommendations  of  the  Instruction  Set  Architecture  Panel  (ISAP) 
formed  in  response  to  the  November  21,  1978  memo  were: 


-  That  a  DoD  Instruction  be  issued  directing  the  DoD  Components  to 
limit  the  number  of  ISAs  Implemented  is  systems  controlled  by  DoD 
Directive  5000.29  and  providing  guidance  in  the  acquisition  of 
defense  systems  that  do  not  fall  in  the  major  systems  category. 

-  Each  Component  identify  a  life-cycle-cost  model  which  it  will  employ 
in  the  application  of  the  Instruction. 

-  A  joint  program  office  be  established  to  competitively  develop  or 
acquire  the  rights  to  a  large-word-size,  large-virtual-address-space 
ISA. 


* ^USDRE  Memorandum,  Defense  System  Embedded  Computer  Architectures,  November 
21,  1978. 


**DUSDRE(AP)  Memorandum,  Defense  System  Embedded  Computer  Architectures, 
April  12,  1979. 
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The  Panel  provided  a  draft  Instruction  for  consideration.  This  early 
draft  was  discussed  widely  and  a  "for  comment"  version  was  completed  on 
October  5,  1979.  It  was  reviewed  on  October  26,  1979  by  the  Management 
Steering  Committee  for  Embedded  Computer  Resources  (MSC-ECR).  The  Committee, 
by  and  large,  agreed  with  the  need  for  the  policy  and  with  the  content  of  the 
draft  Instruction. 


To  assure  that  industry  had  ample  opportunity  to  review  the  proposed 
policy,  an  "Open  Forum"  was  held  at  the  Andrews  Air  Force  Base  theater  on 
November  2,  1979.  This  forum  was  announced  well  in  advance  in  the  Commerce 
Business  Daily  (CBD)1^  As  a  result  of  these  and  other  comments,  a  revised 
draft  was  circulated  for  official  coordination  (SD  Form  106)  on  December  24, 
1980.  This  version  of  the  policy  was  also  provided  to  the  major  industry 
associations  for  comment. 


Agreement  was  not  reached  and  the  Under  Secretary  of  Defense  (Research 
and  Engineering)  decided  that  a  review  by  the  Defense  Sc)ence  Board  would  be 
appropriate  prior  to  any  further  processing  of  the  Instruction. 


2.2  Defense  Science  Board  ECR  Task  Force 

Several  related  issues  cropped  up  which  were  felt  to  deserve  the 
attention  of  such  a  review  as  well.  Accordingly,  the  Under  Secretary  of 
Defense  (Research  and  Engineering)  chartered18  a  Task  Force  to  review  DoD's 
approach  to  acquisition  and  management  of  embedded  computer  resources. 

The  Task  Force  was  asked  to: 

"...review,  evaluate  and  make  recommendations  concerning  the 
acquisition,  management  and  utilization  of  digital  computers  and 
associated  technology  to  support  the  military  mission  of  the 
Department  of  Defense." 

Although  the  instant  and  precipitating  issue  which  spawned  the  Task  Force 
was  DoD's  concern  over  the  need  for  DoDI  5000. 5x  and  Industry's  resistance  to 
it,  there  were  related  questions  which  the  Task  Force  was  specifically  asked 
to  address ,  i «e • : 


1  Commerce  Business  Dally,  U.S.  Department  of  Commerce,  PSA- 7433,  page  18, 
October  12,  1979. 

1 ®USDRE  Memorandum  for  the  Chairman,  Defense  Science  Board,  Defense  Science 
Board  Task  Force  on  Embedded  Computer  Resources  (ECR)  Acquisition  and 
Management,  August  20,  1981.  (cf.  Appendix  1.1) 
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1.  Are  the  management  policies  enunciated  in  DoD  Directive  5000.29, 

DoD  Instruction  5000.31  and  the  proposed  DoD  Instruction  5000. 5x 
appropriate  to  the  present?  If  not,  how  should  they  be  modified 
for  the  upcoming  generation  of  technology?  What  are  the  costs  and 
benefits  of  these  policies  and  to  what  extent  can  they  be 
quantified?  Is  the  implementation  of  these  policies  within  the  DoD 
Components  adequate? 

2.  Are  the  key  embedded  computer  programs  of  the  Department  —  Ada, 
NEBULA19,  NECS20,  and  MIL-STD-1 75021  —  properly  constituted  and 
supported?  What  changes  can  and  should  be  made  to  afford  maximum 
benefits  to  the  Department  as  a  whole?  To  what  extent  should  these 
programs  and  the  policies  of  1  .,  above,  be  considered  for  near-term 
programs  such  as  the  WWMCCS  upgrade  [WIS]? 

3.  Does  the  Management  Steering  Committee  for  Embedded  Computer 
Resources  (MSC-ECR)  serve  a  useful  role?  How  could  it  be  improved 
or  is  there  a  better  mechanism  to  provide  oversight  and  policy 
guidance?  Are  there  other  organizational  issues  of  consequence 
and,  if  so,  what  recommendations  can  be  advanced  for  improvement? 

4.  What  is  the  effect  of  the  Legislative  and  Regulatory  Environment 
upon  the  ability  of  the  Department  of  Defense  to  make  adequate  use 
of  Digital  Technology?  Consideration  should  be  given  to  Public 
Law,  Defense  Acquisition  Regulations,  Component  Regulations, 
business  practices  and  appropriate  policies,  both  central  and 
local. 


1 ^EBULA  is  a  nick-name  for  the  Instruction  Set  Architecture  described  by 
MIL-STD-1 862 .  It  is  the  basis  for  the  Army's  Military  Computer  Family  Program 

20Now  better  described  as  TECR ,  the  Navy  Tactical  Embedded  Computer  Resource 
Program 

21  This  Military  Standard  is  the  Air  Force  standard  16-bit  Instruction  Set 
Architecture* 
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3.  KEY  PROGRAMS 


3.1  Ada*,  The  DoD  Common  Language 


3.1.1  Introduction 

Ada  is  a  modern  high  order  computer  programming  language  which  will 
become  the  standard  language  for  writing  software  for  DoD  embedded  computer 
applications.  The  Ada  Program  extends  well  beyond  simple  language 
standardization  and  will  help  control  the  cost  and  improve  the  quality  of 
software  by  facilitating  the  application  of  modern  software  development 
practices.  The  Ada  Joint  Program  Office  (AJPO),  attached  to  the  DUSD(R&AT), 
is  managing  the  DoD  effort  to  implement,  introduce,  and  provide  life-cycle 
support  for  Ada. 


3.1.2  Background 

In  1975,  the  High  Order  Language  Working  Group  ( HOLWG )  was  established 
—  with  representation  from  Army,  Navy,  Air  Force,  DCA,  NSA  and  DARPA  —  to 
investigate  the  feasibility  of  adopting  a  common  high  order  computer 
programming  language  for  use  on  embedded  computer  systems. 

A  comprehensive  set  of  requirements  was  developed  through  extensive 
coordination  in  DoD,  allied  countries,  industry  and  academe.  Existing 
computer  languages  were  formally  evaluated  against  these  requirements.  No 
existing  language  was  sufficiently  powerful  to  serve  as  the  common  language. 
The  HOLWG  undertook  a  competitive  international  procurement  for  the  design  of 
a  language  to  meet  those  requirements.  Funds  for  this  activity  were  provided 
by  by  the  Services  and  technical  management  was  provided  by  DARPA. 

The  language  design  was  completed  in  May  1979.  Extensive  public  exposure 
and  language  testing  followed,  leading  to  some  refinements  and  a  final 
definition  in  July  1980.  The  Ada  programming  language  was  officially  issued 
as  MIL-STD-1815 ,  dated  December  10,  1980.  Notice  1  to  MIL-STD-1815  was  issued 
on  June  10,  1981  to  indicate  that  Ada*  is  a  trademark  of  the  U.S.  Department 
of  Defense.  The  language  is  named  Ada,  after  Augusta  Ada  Byron,  ostensibly 
the  first  computer  programmer  (who  worked  with  Charles  Babbage  in  the  1800's) 
and  daughter  of  the  poet  Lord  Byron2 2 


22 

For  detailed  historical  development  and  rationale,  see  "Introducing  Ada," 
W.E.  Carlson,  et  al.  Proceedings  of  the  1980  ACM  Annual  Conference,  San  Diego, 
CA,  October  27-29,  1980,  pp  263-271. 
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3.1.3  The  Ada  Program 

The  AJPO  was  established  to  implement,  introduce  and  provide  life-cycle 
support  for  Ada.  It  will  manage  the  maturation  and  evolution  of  the  Ada 
language  and  support  systems.  The  AJPO  will  coordinate  the  development  of  an 
Ada  Programming  Support  Environment  (APSE)  and  encourage  development  of  the 
supporting  culture,  including  management  and  technical  discipline,  to  assure 
the  DoD  a  consistent,  integrated,  programming  system  which  will  enhance 
software  portability  and  afford  maximum  availability  of  common  tools  needed  to 
develop  and  support  defense  systems  software. 

There  are  three  major  Ada  Program  Objectives  in  support  of  this  purpose. 


3. 1.3.1  Language  Standardisation 

First,  the  AJPO  must  ensure  the  implementation  and  maintenance  of  Ada  as 
a  consistent,  unambiguous  standard  recognized  by  the  DoD  and  also  by  the 
widest  possible  community.  Recognition  of  Ada  as  a  standard  is  a  necessary 
step  in  the  realization  of  software  and  people  portability.  A  difficulty 
experienced  by  most  other  computer  languages  is  the  failure  to  control 
adherence  to  the  formal  definition  by  lmplementers  and  the  resulting 
proliferation  of  dialects  through  subseting,  superseting  and  inconsistencies. 

In  pursuing  the  acceptance  of  Ada  as  a  standard  outside  of  the  DoD,  a 
certain  amount  of  control  must  be  shared  with  to  the  standards  bodies.  This 
is  an  advantage  in  that  it  will  provide  a  baseline  for  Ada  and  protect  the 
language  from  future  whimsical  or  capricious  changes  by  the  DoD  or  any  other 
body.  The  AJPO  is  in  the  late  stages  of  the  American  National  Standards 
Institute  (ANSI)  canvass  process  to  gain  acceptance  of  Ada  as  an  ANSI 
Standard.  Through  ANSI  X-3,  the  AJPO  is  pursuing  standardization  with  the 
International  Standards  Organization  (ISO)  Technical  Committee  97, 
Subcommittee  5. 


3. 1.3. 2  Introduction  and  Acceptance 

Second,  the  AJPO  must  ensure  the  smooth  Introduction  and  acceptance  of 
Ada  in  the  DoD  as  early  as  possible  consistent  with  the  needs  of  individual 
Components . 

There  are  a  number  of  projects  which  could  benefit  from  an  early 
introduction  of  the  language.  The  momentum  of  the  Ada  program  has  produced  a 
climate  ripe  for  early  acceptance.  However,  the  advantages  offered  by  the  use 
of  Ada  will  not  be  realized  unless  the  programming  support  environment  is  also 
available.  Therefore,  this  objective  must  balance  the  need  for  an  early 
introduction  of  the  language  against  the  risk  of  a  premature  introduction. 

Ada  should  not  be  employed  on  a  major  DoD  program  until  the  Ada  Programming 
Support  Environment  is  available  to  support  the  needs  of  that  project.  The 
AJPO  is  responsible  for  providing  current  information  to  DoD  program  managers 
who  must  choose  a  language  for  their  programs.  The  AJPO  will  consult  with 
those  program  managers  to  ensure  that  the  appropriate  support  systems  are 
developed.  Use  of  Ada  as  a  Program  Design  language  (PDL)  is  being  promoted 
and  this  strategy  has  been  adopted  by  some  DoD  programs. 


3. 1.3. 3  Support  Systems 

Finally,  the  AJPO  must  ensure  the  provision  of  life-cycle  support  for  Ada 
through  the  development  of  a  robust  Ada  Programming  Support  Environment  (APSE) 
to  improve  productivity  both  in  development  and  in  continued  evolution. 

Ada  is  not  simply  a  new  language.  By  design,  it  incorporates  many  of  the 
features  needed  to  support  modern  programming  practices.  As  such,  Ada 
introduces  a  new  culture  which  will  be  fully  realized  when  a  sophisticated  Ada 
Programming  Support  Environment  is  made  available  and  is  widely  accepted  and 
used.  A  robust  APSE,  complete  with  advanced  development  and  management  tools, 
will  provide  the  opportunities  for  substantial  improvement  in  life-cycle 
software  management.  Although  each  Service  employs  a  different  strategy  in 
the  acquisition  and  management  of  software,  there  will  be  a  set  of  tools  which 
can  be  shared. 

The  Navy  has  been  tasked  to  lead  a  joint  service  review  team  to  identify 
and  recommend  conventions  for  DoD  supported  APSEs  in  support  of  a  Memorandum 
of  Agreement  between  OUSDRE(AM)  and  the  Service  Assistant  Secretaries  to  work 
toward  a  consistent  set  of  APSE  Interfaces.  Contracts  will  be  Initiated  to 
develop  tools  targeted  to  reside  on  the  Army  and  Air  Force  funded 
developments . 

Additional  Ada  Programming  Support  Environments  are  expected  to  be 
developed  independently  by  academe  and  industry.  These  APSEb  will  not  all  be 
compatible  with  the  chosen  conventions.  However,  tools  which  are  sufficiently 
powerful  may  be  modified  to  interface  with  the  APSE.  The  AJPO  will  foster 
development  of  a  highly  complete  and  powerful  APSE  so  that  it  becomes  the 
leading  candidate  to  evolve  as  the  predominant  support  system.  This  should 
encourage  designers  of  independently  developed  tools  to  conform  to  the  chosen 
conventions . 

The  AJPO  is  initiating  preliminary  investigations  which  will  lead  to 
tailoring  of  modern  programming  disciplines,  supported  by  automated  tools,  to 
the  use  of  Ada.  This  activity  is  expected  to  Increase  productivity  and 
improve  the  quality  of  software. 

A  consequence  of  this  objective  is  a  requirement  for  close  cooperation 
with  the  Industrial  sector  to  encourage  acceptance  of  the  language  and 
development  of  Ada  products  in  the  marketplace.  Cooperation  outside  the  U.S. 
has  also  brought  much  vital  technical  input.  It  has  made  possible  an  exchange 
with  our  allies  and  a  more  viable  relationship  with  the  multinational  computer 
and  defense  industry. 


3.1.4  Status 

Several  contracts  for  Ada  developments  are  either  under  way  or  planned. 
The  AJPO  is  managing  a  few  contracts  such  as  those  with  Honeywell,  SofTech, 
and  Intermetrics.  Honeywell  is  revising  the  language  reference  manual  (LRM), 
which  is  the  principal  document  defining  the  language,  in  conjunction  with  the 


ANSI  standardization  process.  The  new  LRM  should  be  ready  early  in  1982. 
SofTech  is  adding  tests  to  the  Ada  Compiler  Validation  Capability  (ACVC)  to 
ensure  compliance  with  the  revised  LRM  to  correspond  to  the  expected  ANSI 
standard. 

Most  Ada  Program  contracts  are  managed  by  the  Military  Departments  using 
their  own  funds  as  well  as  those  provided  by  the  AJPO.  The  Army's  contract 
with  New  York  University  has  produced  an  interpreter  which  runs  on  the 
VAX-11/780  and  which  is  available  through  NTIS.  The  interpreter  is  being 
modified  to  conform  to  the  revised  LRM  and  will  be  validated  by  the  ACVC  this 
spring. 

SofTech,  also  under  contract  to  the  Army,  is  scheduled  to  deliver  the  Ada 
Language  System  (ALS),  a  Minimal  Ada  Programming  Support  Environment  (MAPSE) 
hosted  on  the  VAX,  in  late  1982.  The  Air  Force  expects  to  let  a  contract  in 
March  for  the  Ada  Integrated  Environment  (AIE),  a  MAPSE  hosted  on  IBM  and 
Interdata  machines  for  delivery  in  1984.  The  Navy  is  leading  a  joint  service 
KAPSE  Interface  Team  (KIT)  to  identify  and  recommend  conventions  for  DoD- 
supported  APSEs.  The  Navy  will  initiate  contracts  to  develop  tools,  targeted 
to  reside  on  the  ALS  and  the  AIE,  which  will  serve  to  reveal  issues  relevant 
to  tool  transportability  and  will  provide  tools  useful  in  both  the  ALS  and  the 
AIE. 

Several  commercial  efforts  have  been  announced,  including  compilers  by 
Western  Digital,  TeleSoft,  and  Intel  which  are  currently  incomplete,  when 
measured  against  the  complete  Ada  language  specification.  All  three  companies 
have  announced  plans  to  market  complete,  validated  compilers. 
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3.2  Military  Computer  Family  (MCF) 

The  Army's  Military  Computer  Family  Program  stems  from  a  vital  need  for 
system  survivability  on  the  battlefield.  Computers  have  become  an  essential 
part  of  Army  battlefield  systems  which  perform  the  functions  of 
communications,  command  and  control,  intelligence  analysis,  surveillance, 
target  acquisition,  air  defense,  weapons  control,  fire  support,  electronic 
warfare,  navigation,  equipment  control,  and  combat  support  services.  These 
computers  operate  in  jeeps,  armored  vehicles,  aircraft,  vans,  etc.  and  must 
survive  on  the  nuclear  battlefield.  These  computers  should  not  be  confused 
with  those  used  in  normal  business  and  office  automation  functions  in  DoD  and 
the  Services. 

The  Army  conducted  a  Post  Deployment  Software  Support  (PDSS)  study  and 
developed  a  plan  to  support  its  systems  on  the  battlefield.  It  identified 
extensive  proliferation  in  software  support  systems;  over  44  assembly 
languages  and  dialects  of  higher  order  languages  were  being  used.  Current 
estimates  show  over  50  different  computer  types  to  be  supported  logistically . 
Proliferation  significantly  increases  the  cost  and  complexity  of  software 
development  and  support  as  well  as  hardware  logistics,  maintenance,  training, 
and  acquisition.  The  goals  of  the  Army's  Ada  and  MCF  Programs  are  to  make  the 
Army's  battlefield  automated  systems  survivable,  supportable  and  affordable. 
Following  review  by  a  Task  Force  from  the  Army  Science  Board  in  early  1980, 
the  Army  established  policy23  and  has  implemented  programs  in  three  areas 
—  software  support,  ISA,  and  standard  hardware. 

One  of  the  major  benefits  to  be  derived  from  this  standardization  program 
will  be  the  reduction  of  the  system  development  cycle  time.  By  providing 
adequate  software  development  facilities  and  logistically  supported  computers 
to  new  systems,  adequate  early  prototyping  of  software  can  be  accomplished. 

Software  development,  maintenance,  and  configuration  management  for 
systems  deployed  to  tactical  units  on  the  battlefield  is  done  centrally.  These 
systems  are  too  complex  to  be  programmed  in  the  field.  Acknowledging  Ada  as 
the  eventual  DoD  standard,  the  Army  dropped  TACPOL  as  its  standard  language 
and,  in  a  coordinated  program  with  the  Ada  Joint  Program  Office  and  the  other 
Services,  is  developing  the  Ada  Language  System  (ALS).  The  ALS  is  hosted  on  a 
commercial  computer  —  the  DEC  VAX-1 1/780  —  and  is  required  to  be 
transportable  to  others  to  assure  future  competition.  It  makes  use  of 
commercially-developed  hardware  and  operating  systems  in  the  software 
development  and  maintenance  environment  and  will  provide  operational  software 
to  be  fielded  and  run  on  computers  in  the  field.  The  ALS  will  be  available 
initially  in  early  1983.  The  Army's  preference  for  Ada  does  not  prevent  use  of 
other  languages  in  DoDI  5000.31. 


23 


AR  1000-1,  Basic  Policies  for  Systems  Acquisition,  May  1,  1981 
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The  Instruction  Set  Architecture  (ISA)  to  be  used  in  MCF  is  MIL-STD-1862 
(NEBULA),  which  has  had  extensive  review  by  the  government  and  industry24. 
NEBULA  is  a  modern,  efficient,  32-bit  ISA  which  is  vendor  independent  (see 
Section  4. 3. 2. 3)  and  has  allowed  wide,  open  competition  for  implementations. 
There  were  12  bidders  for  the  MCF  advanced  development  phase.  NEBULA  is 
stipulated  to  be  "in  the  public  domain"  and  available  for  use  by  industry  in 
general.  Wide  use  of  NEBULA  would  create  a  strong  knowledge  base  for  the  DoD 
and  competition  base  for  future  production.  Nonmilitarized  or  "commercial"  MCF 
versions,  if  cost  effective,  could  be  used  in  many  DoD  applications, 
particularly  in  Command  and  Control. 


At  th>  hardware  level,  standard  products  would  provide  maximum 
interchangeability  of  hardware  for  survivability  and  maximum  savings  in 
logistics,  maintenance,  and  training  costs.  Standard  hardware  allows  savings 
in  all  areas  from  the  production  line  to  diagnostics  and  sparing.  But,  since 
technology  is  moving  rapidly,  positive  plans  must  be  made  for  the  introduction 
of  new  technology  to  avoid  technological  obsolescence.  The  ISA  and  other 
interfaces,  which  will  be  maintained  as  upward-compatible  standards,  will 


provide  maximum  commonality  for  software  savings  while  new  technology  is 
introduced  into  subsequent  implementations.  A  study25  and  Army  inquiries  show 


that  benefits  from  new  hardware  technology  make  it  advisable  to  have 
subsequent  implementations  in  4  to  7  years  for  new  weapon  systems.  Since  the 
ISA  is  vendor  independent  and  subsequent  implementations  could  be  produced  by 


anyone,  maximum  access  to  competition  is  afforded.  This  is  a  form  of  Pre- 
Planned  Product  Improvement,  P3I. 


Currently,  three  contractors  —  GE/TRW ,  RCA,  and  Raytheon  —  are 
competing  for  two  full  scale  development  (FSD )  contracts.  Each  contractor  is 
free  to  select  a  technology  and  internal  design  approach.  Areas  of 
competition  are: 


1.  Reliability  and  maintainability, 

2.  Life-cycle  costs, 

3.  Power  dissipation, 

4.  Technology  and  hardware  architecture, 

5.  Producibility, 

6.  Size  and  weight. 


24The  Army's  MIL-STD-1862  and  the  Military  Computer  Family,  Technical 
Directions,  vol.7,  no.  2,  Summer  1981,  page  29-40,  IBM  Federal  Systems 
Division 


^Navy  Computer  Accreditation  Study,  IBM,  Contract  N00014-79-C-0986 


7.  Speed  and  memory  capacity, 


Performance  measured  in  these  parameters  will  be  evaluated  against  the 
requirements  of  the  battlefield.  Each  contractor  will  deliver  a  prototype  of 
the  super  minicomputer  (AN/UYK-41)  and  the  microcomputer  (AN/UYK-49)  in  early 
1983.  Maximum  competition  is  being  maintained.  Chip-sets  and  a  single  board 
computer  for  smaller  applications  (components  ot  the  AN/UYK-49)  will  be 
available  to  embed  in  other  equipment. 

During  FSD,  the  best  two  designs,  using  1984  technology,  will  compete  for 
one  production  contract  scheduled  for  1986.  Pre-production  models  with  ILS 
packages  will  be  available  for  testing  and  early  use.  A  fixed-price, 
requlrements-type  contract  (unit  prices  established  during  competition)  is 
currently  planned  for  award  to  the  winner  of  the  competitive  fly-off.  The 
ordering  period  will  be  five  years.  The  primary  production  period  is  expected 
to  be  7  years  with  follow-on  for  repair  parts.  Standard  MCF  computers  will 
become  available  from  the  production  line  in  1987  for  use  in  systems.  Other 
form  factors,  as  needed  can  be  standardized  as  the  logistics  situation 
dictates. 


During  the  production  phase,  currently  planned  for  1986  to  1993, 
resolicitation,  open  to  all  manufacturers,  will  start  the  next  iteration  of 
MCF.  Naturally,  if  technology  advances  more  slowly,  the  Army  has  the  option  to 
“product  improve”  the  current  versions  or  establish  multiple  producers  as  the 
situation  dictates. 

For  the  interim  period,  the  Army  plans  to  limit  unnecessary  proliferation 
of  new  ISAs  and  software  support  systems.  Choices  for  new  systems  can  be  made 
from  those  which  are  currently  planned  to  be  supported  on  the  battlefield. 

Back  up  to  MCF  hardware  is  planned  from  the  Ada  Language  System  with 
additional  code  generators  to  other  ISAs.  A  standard  product  line  will  be 
evolved  from  current  equipment  for  which  full  support  is  planned.  Additional 
"soft"  or  "AD"  MCF  models  will  be  used  by  programs  just  getting  started  and 
for  support  software  development. 


3.3  TgCR,  The  Navy  Tactical  Embedded  Computer  Resource  Program 

Because  of  the  particularly  severe  problems  surrounding  the  support  of 
computers  at  sea,  the  Navy  decided  to  limit  the  number  of  computer  types  and 
the  variety  of  languages  some  15  years  ago.  As  a  result,  most  Navy  systems 
are  designed  around  two  principal  machines,  the  AN/UYK-7  and  the  AN/UYK-20. 

The  Navy  standard  airborne  computer,  the  AN/AYK-14,  is  based  on  an  ISA  which 
is  upward  compatible  from  the  AN/UYK-20. 

The  Navy  has  5000  standard  militarized,  tactical  "embedded"  computers  in 
450  types  or  tactical  system  using  over  50  million  lines  of  computer  program 
code.  Eveii  though  most  of  these  computers  will  remain  on  active  service  for 
another  10  to  20  years,  the  current  computers  are  approaching  obsolescence  and 
are  experiencing  speed  and  memory  saturation  in  many  applications.  In  mapping 
out  a  program  for  successors  to  these  computers,  the  Navy  has  considered 
constraints  of  physical  interchangeability  to  maximize  readiness  of  systems  at 
sea  and  to  minimize  support  costs,  as  well  as  the  constraints  of  a  large 
investment  in  software,  with  which  the  new  computer  must  be  compatible  or 
which  must  be  recoded  —  with  at  least  the  original  development  cost. 

These  new  standard  militarized  computers  —  the  AN/UYK-43  and  the 
AN/UYK-44  —  are  under  competitive  full  scale  engineering  development  to 
assure  both  high  technology  implementation  and  lowest  production  price.  It  is 
expected  that  the  AN/UYK-43  production  contractor  will  be  competitively 
selected  in  September,  1983  and  the  AN/UYK-44  production  contractor  selected 
in  January,  1983.  Production  contracts  in  both  cases  will  be  five-year, 
fixed-price  "requirements"  contracts.  Options  beyond  the  first  five  years  are 
open  and  are  being  evaluated. 

These  computers  will  fulfill  the  needs  of  the  Navy  for  standardization 
and  software  Investment  capture  by  upward  compatibility  with  the  existing 
"mainframe"  AN/UYK-7  and  the  AN/UYK-20  "minicomputer”,  respectively.  The 
AN/UYK-44  mlcro/mlni  series  is  also  software  compatible  with  the  new  AN/AYK-14 
standard  Navy  airborne  computer.  Software  upward  compatibility  is  achieved  in 
each  machine  by  "emulating"  the  ISAs  of  predecessor  machines  while  also 
extending  the  instruction  sets  with  additional  more  powerful  instructions 
which  may  be  used  arlth  new  software. 

The  AN/UYK-43  will  be  delivered  to  the  Navy  for  testing  in  March  1983. 

It  will  run  up  to  nine  times  as  fast  as  the  AN/UYK-7  and  will  initially 
contain  up  to  1.25  million  words  of  memory  in  a  single  enclosure.  AN/UYK-44 
embeddable  card  sets  were  delivered  by  both  contractors  to  the  Navy  for 
testing  in  December  1981;  complete  AN/UYK-44  computers  will  be  delivered  for 
testing  in  September  1982.  The  AN/UYK-44  will  run  up  to  twice  the  speed  of 
the  AN/UYK-20  and  will  contain  up  to  0.5  million  words  in  a  single  enclosure. 
In  both  cases,  the  computers  have  a  modular,  "building  block"  construction 
using  standard  components  to  minimize  at-sea  logistics  costs  and  to  allow  easy 
configurability  to  different  performance  requirements. 

Navy  units  afloat  must  carry  sufficient  spare  parts  on  board  to  ensure 
self  sufficiency  during  a  90-day  mission.  It  is  estimated  that  the  minimum 
cost  of  a  fleet  wide  Inventory  of  spares  per  type  of  computer  used  throughout 


the  fleet  is  $30,000,000.  This  Is  so  because  the  low  parts  consumption  demand 
by  modern  high-reliability  computers  allows  up  to  50  same-type  computers  on  a 
single  ship  to  be  supported  by  one  basic  "kit"  of  spares.  However,  if  only 
one  of  a  type  of  computer  is  carried  on  board  it  must  be  supported  by  a  kit  of 
"insurance-item"  spares  costing  at  least  a  quarter  of  the  cost  of  the  basic 
full  kit.  Uith  this  absolute  minimum  sparing,  the  computer  will  suffer  a 
reduced  operational  availability  due  to  the  need  to  occasionally  wait  for  off- 
board  repair  parts  not  in. the  minimum  insurance-item  kit.  The  key  to 
obtaining  highest  computer  operational  availability  while  at  the  same  time 
minimizing  logistics  costs  is  clearly  through  using  the  same  computer  types 
repeatedly  throughout  the  many  systems  on  a  ship. 

A  key  requirement  in  the  development  of  these  computers  is  achievement  of 
unprecedented  improvements  in  reliability,  maintainability  and  availability 
through  use  of  high  reliability  technology,  fault  tolerant  design,  redundant 
critical  circuits,  self  testing,  and  fault  diagnosing  capabilities.  As  an 
example  of  internal  diagnostic  capabilities  for  the  AN/UYK-43  "mainframe” 
computer,  the  length  of  the  maintenance  training  school  for  enlisted 
maintalners  has  been  cut  from  the  15  weeks  required  for  the  AN/UYK-7  to  one 
week  for  the  AN/UYK-43.  Also,  the  machines  will  be  capable  of  maintenance  and 
repair  by  user  system  technicians  (e.g.,  fire  control  technicians,  missile 
technicians,  sonar  technicians)  rather  than  specifically  trained  computer 
technicians.  Initial  program  direction  required  that  these  reliability, 
maintainability,  and  availability  improvements  would  take  precedence  over 
performance  Improvements  in  the  new  computers  if  necessary.  However,  to  date, 
no  compromises  have  been  necessary  and  specifications  of  both  types  are  being 
met  or  exceeded.  All  developments  are  on  schedule. 

Even  with  the  Improved  performance  capabilities,  unit  costs  of  the  new 
standard  computers  are  targeted  to  be  no  more  than  the  current  standard 
computers.  It  is  is  forecast  that  the  various  using  Navy  projects  will  buy 
approximately  1,500  of  the  "mainframe"  AN/UYK-43s  and  20,000  of  the  smaller 
AN/UYK-44  in  its  embeddable  and  complete  computer  versions. 

Despite  the  preservation  of  existing  support  and  applications  software 
which  these  computers  will  allow,  while  transitioning  projects  and  systems  to 
the  new  DoD  high  order  programming  language,  Ada,  it  is  still  forecast  that 
there  will  be  a  quantum  leap  in  the  amount  of  new  computer  software  required 
for  Navy  tactical  systems  because  of  new  operational  requirements.  In  the 
face  of  a  forecast  nationwide  short  fall  of  thirty  percent  in  qualified 
computer  programmers  within  ten  years,  the  Navy  must  also  Intensify  efforts  to 
attract,  train,  and  retain  qualified  progratmners ,  to  modernize  and  automate 
software  engineering  practices,  and  to  invest  in  computer  software  support 
centers  to  fully  capitalize  on  the  forthcoming  hardware  performance  and  price 
"bonanza". 
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3.4  MIL-STD-1750 ,  The  Air  Force  Approach 


3.4.1  Overview 

The  Air  Force  will  Implement  DoDI  5000. 5x  as  a  logical  extension  of 
current  Air  Force  policy,  standardizing  on  two  of  the  listed  types: 

-  M1L-STD-1750A,  ” 16-Bit  Computer  Instruction  Set  Architecture,"  and 

-  MIL-SrD-1862A,  "Instruction  Set  Architecture  for  the  Military 

Computer  Family  (NEBULA)." 

The  Air  Force  approach  fosters  competition  and  encourages  technology 
insertion  by  treating  the  ISA  as  an  interface  between  programmer  and  machine, 
or  between  compiler  and  machine.  By  standardizing  on  the  ISA,  the  Air  Force 
can  exploit  a  common  base  of  software  support  resources;  people,  facilities 
and  tools.  The  Air  Force  will  not  "lock  in"  on  a  single  hardware  standard;  by 
avoiding  a  Service-wide  hardware  standard,  competition  among  vendors  will 
exist  in  development,  in  production  and  during  system  modifications.  This 
approach  has  already  yielded  improved  designs  and  more  competitive  pricing  in 
several  systems  acquisitions  including  the  F-lll  Digital  Upgrade  Program  and 
the  F-5G  II  fighter  aircraft. 

Although  the  Air  Force  logistics  environment  differs  markedly  from  that 
of  other  Services,  additional  levels  of  standardization  beyond  the  ISA  will 
prove  valuable.  Particular  emphasis  will  be  placed  on  standard  interfaces, 
such  as  MIL-STD-1553*-6  and  MIL-STD-176027. 


3.4.2  MIL-STD-1750A 

MIL-STD-1750A  is  the  Air  Force  developed  and  owned  ISA.  Developed 
through  work  at  the  Air  Force  Avionics  Laboratory,  the  ISA  was  originally 
intended  for  use  as  the  central  computer  in  an  avionics  suite.  Refinements 
resulting  from  open  forum  discussions  between  industry  and  Government  expanded 
the  ISA’s  memory  Addressability  and  improved  its  ability  to  effectively 
execute  programs  written  in  modern  high  order  languages. 

The  MIL-STD-I750A  Users  Group  —  a  broad  base  of  government  and 
contractor  developers  and  users  —  has  been  instrumental  in  the  acceptance  and 
improvement  of  the  standard.  It  is  now  concentrating  on  the  support  resources 
needed  to  exploit  fully  the  benefits  of  the  standard.  At  a  recent  meeting  of 


2^MIL-STD-1553,  Aircraft  Inte mal  Time  Division  Command /Response  Multiplex 

Data  Bus. 

27MIL-STD-1760,  Aircraft/Store  Electrical  Interconnection  System. 
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«  the  Users  Group,  there  were  over  120  participants  representing  some  40 

corporations. 

The  Mil-STD-1750  Control  Board,  an  Air  Force  body,  evaluates  all 
recommendations  of  the  Users  Group  and  is  responsible  for  the  control  of  the 
standard.  At  this  time,  there  is  a  minimum  three-year  freeze  of  the  ISA  to 
allow  economical  implementation  and  use  over  several  applications.  Of  course, 
if  critical  problems  are  uncovered  during  the  implementations,  appropriate 
fixes  must  be  authorized. 

The  Embedded  Computer  Standardization  Program  Office  (ECSPO)  is  a  joint 
AFSC/AFLC  unit  which  manages  Air  Force  work  to  support  standard  systems  with 
standard  tools.  The  ECSPO  is  working  to  certify  and  maintain  a  core  set  of 
compilers,  code  generators  and  other  software  development  and  maintenance 
tools. 

Certification  of  computers  to  MIL-STD-1750  is  underway  at  the 
Aeronautical  Systems  Division  (ASD)  Systems  Engineering  Avionics  Facility 
(SEAFAC ) ;  Three  firms'  computers  have  passed  the  certification  procedure  and 
others  await  their  turn. 

At  least  18  contractors  and  foreign  agencies  are  implementing  MIL- 
STD-1 750A  for  a  variety  of  applications  ranging  from  the  Army  Division  Air 
Defense  System  to  the  F-16  Multinational  Staged  Improvement  Program  (MSIP). 
The  technologies  employed  range  from  bi-polar  integrated  circuitry  to  VHSIC 
chips  to  radiation-hardened  CMOS /SOS. 


3.4.3  MIL-STD-1 862A,  NEBULA 

Because  no  one  ISA  can  cost-effectively  cover  the  entire  spectrum  of 
computer  requirements  for  modern  systems,  the  Air  Force  plans  to  require 
either  the  MIL-STD-1 750A  or  MIL-STD-1 862A  instruction  set  architecture  for 
embedded  computers.  The  Air  Force  has  joined  the  Army  as  an  equal  member  of 
the  MIL-STD-1 86 2A  Control  Board.  As  with  MIL-STD-1 750A,  the  Air  Force  does 
not  plan  to  adopt  a  Service-wide  standard  "black  box";  open  competition  and 
technology  insertion  will  be  encouraged.  For  applications  where  the  timing  of 
the  MCF  hardware  program  matches,  it  is  likely  that  the  Air  Force  will  be  able 
to  benefit  from  the  Army's  quantity  buys. 


4.  GENERAL  DISCUSSION 


4.1  Standardisation  Perspective 

The  DoD  Embedded  Computer  Resources  (ECR)  environment  today  reflects  the 
history  of  problems  which  of  the  Military  Departments  have  encountered  in 
their  attempts  to  use  computers  in  systems  which  must  survive  and  Interoperate 
in  the  wartime  environment  to  accomplish  mission  objectives.  The  effects  of 
hardware  and  software  proliferation,  low  interoperability  and 
interchangeability,  and  maintenance  and  logistics  difficulty  have  resulted  in 
high  life-  ycle  costs  and  mission  degradation.  The  effects  on  each  Service 
differ  only  in  degree.  In  recognition  of  this  situation,  OSD  instituted  the 
policies  discussed  in  Section  2.1.  These  policies  are  intended  to  control 
embedded  computer  resources  and  related  activities.  The  objectives  of  this 
control  are  to  reduce  time  to  deployment,  life-cycle  cost,  training,  equipment 
proliferation,  unnecessary  replication,  complexity  of  system  change,  and  to 
enhance  maintainability,  interoperability,  survivability  and  hardware 
interchangeability. 

To  achieve  these  objectives,  many  levels  of  standardization  and/or 
coordination  must  be  considered.  Figure  4-1  lists  possible  levels  or  areas  of 
control.  As  Indicated,  several  of  these  levels  are  actively  being  considered 
for  standards  or  have  existing  standards.  The  Task  Force  concentrated  its 
attention  on  these  areas  and  our  findings  and  recommendations  with  respect  to 
them  are  contained  in  Chapter  5. 


STANDARDIZATION  OBJECTIVES 
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Standardization  at  some  of  these  levels  is  currently  under  way, 
standardization  at  additional  levels  should  be  initiated  and  the  remaining 
levels  should  remain  relatively  unconstrained.  Among  the  Instructions  which 
already  exist  is  DoDI  5000.31  which  standardizes  on  a  set  of  HOLs  and  proposes 
convergence  to  a  single  HOL,  Ada.  The  Ada  Joint  Program  Office  (AJPO),  which 
is  conducting  this  effort,  is  also  moving  in  the  direction  of  standardizing  a 
software  support  environment  and  support  software  interfaces.  The  Task  Force 
believes  the  Ada  software  standardization  program  as  presently  constituted  is 
sound  and  should  be  supported.  Draft  DoDI  5000. 5x  proposes  standardization  on 
a  small  set  of  ISAs  and  expresses  a  desire  to  converge  this  set  to  some 
“minimum"  number. 

Task  Force  views  on  DoDI  5000. 5x  are  discussed  is  Section  5.1.  The 
standardization  concept  is  supported.  Standardization  at  the  hardware  box 
level  is  in  effect  in  both  the  Army  and  Navy.  Owing  to  the  logistic  support 
problems  of  these  two  Services,  standardization  on  ISA  implementation  appears 
both  prudent  and  cost-effective.  All  Military  Departments  have  adopted  a  set 
of  standard  electrical  communications  interfaces.  The  Task  Force  believes 
these  are  essential  to  a  comprehensive  ECR  management  endeavor.  While  the 
Task  Force  endorses  these  standardization  initiatives,  it  recognizes  a  need  to 
take  a  broader- approach  to  standardization.  This  can  be  accomplished  by 
coupling  the  current  initiatives  with  additional  attention  to  other  control 
levels  designated  in  Figure  4-1.  We  strongly  believe  that  standardization  at 
only  the  HOL  and/or  ISA  level  will  not  be  sufficient  to  accomplish  the  desired 
control  objectives.  Among  the  standards  which  must  be  added  are: 


1.  Standard  software  support  support  environment  such  as  as  that 
proposed  by  the  AJPO,  standard  runtime  operating  system(s). 

2.  Protocols. 

3.  Data  dictionaries  and  descriptors  and,  eventually, 

4.  A  user  Interface. 

At  present,  it  does  not  appear  that  benefit  would  be  gained  from 
additional  control  of  hardware  modules  or  components. 


4.2  High  Level  Language  (HLL)  Machines . 

The  bulk  of  today's  installed  computers  reflect  the  classical  von  Neumann 
architecture  in  the  sense  that  the  instructions  which  the  computer  hardware 
can  understand  and  execute  are  so-called  low  level.  Such  Instructions 
typically  deal  with  fundamental  machine  operations  such  as  add,  subtract, 
store  memory,  read  memory.  Computer  programs  written  directly  in  the  language 
of  the  machine  are  referred  to  as  machine  language  programs  or,  sometimes 
loosely,  assembly  language  programs.  However,  there  are  a  large  number  of  so- 
called  higher  order  languages  used  by  programmers  which  have  the 
characteristic  that  statements  made  in  such  languages  are  more  Involved, 
closer  to  a  natural  language  of  English,  mathematics,  or  a  specialized  field 
of  application,  but  not  directly  comprehensible  to  a  machine.  Hence,  in 


present  mrt  there  exists  a  special  software  package  called  a  compiler  which 
accepts  a  computer  program  written  in  an  HOL  (usually  called  the  source 
language)  and  produces  an  output  in  the  language  of  the  machine  on  which  the 
program  is  to  execute  (the  target  or  object  language). 

There  is  growing  research  Interest  in  a  category  of  machines  commonly 
called  a  High  Level  Language  (HLL)  machine  or  said  to  have  a  high  level 
architecture^  .  Another  term  for  such  a  machine  is  an  HOL  machine,  and 
conversely  another  term  for  a  high  order  programming  language  is  a  high  level 
language.  If  an  HLL  machine  —  and  this  seems  to  be  the  preferred  term 
—  directly  accepts  a  high  level  language  for  execution,  then  it  is  said  to  be 
a  direct  e~  ecution  HLL  machine.  Conversely,  if  the  computer  program  in  an  HLL 
is  first  run  through  a  translator  —  which  is  typically  the  front  end  portion 
of  a  compiler  —  to  convert  problem  statements  in  an  HLL  to  corresponding  ones 
in  some  intermediate  language  which  then  becomes  the  input,  such  an  HLL 
machine  is  said  to  be  an  indirect  execution  machine.  Thus,  the  thrust  of 
contemporary  research  on  HLL  machines  can  be  encapsulated  in  the  question: 

"How  much  of  the  compiler  software  can  be  absorbed  directly  into 
the  hardware  and  architecture  of  the  computer  per  se?" 

To  say  it  differently: 

"How  close  can  the  interface  between  the  programmer  plus  the 
language  which  he  uses  be  moved  toward  the  computer  hardware?" 

Obviously,  there  are  a  whole  series  of  corollary  questions.  Among  them 

are: 

-  What  are  the  payoffs  of  such  a  new  architecture? 

-  What  are  the  costs  of  su  i  a  new  architecture? 

-  Is  it  technically  feasible? 

-  Should  such  new  architectures  be  considered  for  all  computer 
applications  or  are  there  ones  in  which  more  conventional  structures 
still  remain  appropriate  or  preferred? 

After  a  computer  program  is  written  and  tested,  there  is  a  phase  known  as 
validation  and  verification  (V&V)  which  is,  in  effect,  an  extremely  detailed 
step-by-step  examination  to  assure  that  it  also  executes  as  Intended  without 
anomalies  of  behavior.  The  intent  is  to  demonstrate  that  the  progxam  does 
what  it  is  supposed  to  do  and  properly  so.  However,  in  today's  V&V  state  of 


28 
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Che  art,  it  is  impossible  to  demonstrate  that  a  computer  program  does  not  do 
what  it  is  not  supposed  to  do;  and  therefore  in  an  absolute  sense,  the  V&V 
process  cannot  be  carried  to  its  theoretical  completion.  As  a  program  written 
in  an  HLL  is  passed  through  the  compiler  to  produce  an  executable  machine- 
level  program,  a  large  amount  of  intricate  manipulation  occurs.  Thus,  it  is 
possible  for  behavior  intended  by  the  programmer  at  the  HLL  level  to  be 
subverted  or  changed  in  subtle  ways  by  the  process  of  compilation.  Hence,  to 
assure  the  maximum  certainty  that  the  program  is  as  intended,  V&V  efforts  are 
typically  carried  out  at  the  machine  language  level  which  implies  that  such 
tasks  are  tedious,  enormously  detailed,  time  consuming  and,  therefore, 
expensive. 

Limited  experience  in  doing  V&V  at  the  HLL  level  suggests  that  it  is 
feasible  for  a  large  fraction  of  the  operational  programs  for  a  weapon  system 
(for  example,  the  algorithms  contained  in  such  programs)  to  satisfactorily  be 
done  in  this  way^.  However,  a  large  part  of  such  operational  programs  for 
so-called  real-time  code,  probably  still  must  be  accomplished  at  the  machine 
language  level  unless  extremely  strict  discipline  and  standardization  of  both 
programming  and  compiler  details  are  enforced.  Furthermore,  V&V  at  the  HLL 
level  (but  then  compiled)  may  need  substantial  special  hardware  adjuncts,  for 
example,  to  make  the  program  stop  at  a  particular  memory  or  symbol  location 
—  details  commonly  obscured  by  the  compiler.  There  may  also  be  needed 
special  software  aids  embedded  in  the  compiler  to  extract  from  it  details 
which  are  not  commonly  available.  Alternatively,  special  computer 
architectures  can  be  imagined  which  provide  extra  space  in  the  computer  word 
for  details  associated  with  subsequent  V&V. 

Since  the  process  of  compilation  is  a  complex  manipulation,  an  HLL 
machine  should  permit  more  ready  discovery  of  errors  made  during  the  original 
programming  process.  In  this  regard  such  machines  exhibit  the  same 
characteristics  as  those  which  operate  in  the  so-called  interpretation  mode 
and  directly  accept  statements  in  an  appropriate  HLL.  Typically,  the  widely 
available  so-called  home  or  hobby  level  computers  (e.g.,  Apple,  TRS-80,  Atari, 
Sinclair)  operate  interpretively  in  a  language  called  BASIC.  Since 
interpretative  languages  and  machines  facilitate  not  only  programming  per  se 
but  also  testing  and  debugging,  an  HLL  machine  should  have  the  same 
characteristic  .  There  would  then  be  less  opportunity  for  the  program  to  do 
something  unforeseen  by  its  creator. 

On  the  other  hand,  an  HLL  machine  obviously  implies  more  hardware 
although  it  is  not  clear  that  such  an  issue  is  significant  in  the  forthcoming 
VHSIC  era.  Clearly,  however,  a  direct  execution  machine  must  be  modified 
anytime  changes  are  made  to  the  language  which  it  accepts,  or  alternatively 
some  special  features  must  be  incorporated  into  it  to  permit  changes  or 
additions  as  the  language  which  it  tracks  evolves.  An  indirect  execution 
machine  is  more  flexible  in  this  sense  because  changes  in  the  language  would 
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Two  bodies  of  experience  are  the  DAIS  Program  conducted  by  the  Air  Force 
Avionics  Laboratory  and  the  Bell  Laboratories  work  with  programs  for  the  new 
digital  ESS  switching  center  machines 
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Imply  only  changes  In  Che  translator  or  preprocessor  which  is  a  software 
package  hosted  on  a  machine  of  choice. 

There  are  a  number  of  significant  research  issues.  Among  them  are: 


-  The  NEBULA  (MIL-STD-1862A)  Instruction  Set  Architecture  (ISA)  of  the 
Army's  MCF  program  approximates  an  HLL  machine  in  that  many  of  its 
instructions  are  identical  to  one  in  some  HLL.  Especially,  the 
NEBULA  ISA  is  said  to  be  "Ada-oriented”  because  many  Ada 
instructions  map  directly  onto  a  corresponding  NEBULA  one.  But  how 
far  should  one  go  in  matching  the  instruction  set  architecture  of  a 
machine  to  one  particular  HLL?  Clearly,  the  Department  of  Defense 
will  continue  to  support  several  high-level  programming  languages, 
and  hence  a  standard  for  an  Instruction  set  architecture  should 
presumably  accommodate  more  than  one  of  them.  Does  the  NEBULA 
language  go  as  far  as  i *asonably  appropriate?  The  answers  to  such 
questions  obviously  are  a  function  of  hardware  technology;  they  are 
obviously  related  to  the  ngidlty  and  completeness  of 
standardization  that  the  Department  of  Defense  wishes  to  impose;  and 
they  obviously  influence  the  complexity  of  hardware  designs. 

-  What  about  the  V&V  process  with  an  HLL  machine?  How  significant  are 
the  advantages?  How  significant  are  the  savings  measured  eitl»~r  in 
dollars  or  elapsed  time?  Are  there  any  special  features  needed  in 
the  machine  to  facilitate  the  V&V  process? 

-  What  about  real-time  applications  which  characterize  the  bulk  of  the 
Department  of  Defense  operational  software?  Are  they  readily 
handled  in  an  HLL  machine?  Are  there  special  programming 
conventions  which  must  be  imposed  rigidly? 

-  For  the  indirect  execution  machine,  what  about  the  intermediate 
language  that  separates  the  original  programmer-created  program  from 
the  machine?  What  are  its  details?  What  flexibility  is  needed  in 
it?  Can  one  be  designed  that  will  accommodate  a  broad  variety  of 
HLL  languages? 

-  How  does  the  support  software  for  an  HLL  differ  from  the  customary 
utility  packages  now  expected  by  the  development  programmer? 

-  What  does  an  HLL  machine  do  for  computer  security?  Especially  what 
are  the  implications  for  the  operating  system  and  the  security 
safeguards  which  it  must  contain? 

There  is  a  small  amount  of  research  presently  underway: 


-  The  Air  Force  Avionics  Laboratory  has  a  contract  with  Sanders 
Associates . 

-  Professor  Flynn  at  Stanford  University  and  Professor  Chu  at  the 
University  of  Maryland  are  both  involved  in  research. 


-  The  Federal  Systems  pivlslon  of  IBM  has  examined  HLL  machines  with 
IR&D  funds. 

-  Sperry  Univac  is  working  on  a  GENEX  architecture. 

-  The  Aerospace  Corporation  with  corporate  funds  is  constructing  an 
experimental  ARC  machine  with  an  HLL  architecture. 

Interestingly,  one  commercial  machine  is  considered  a  high-level  machine 
or  at  least  to  have  high-level  features^  .  In  addition,  the  Western  Digital 
Corporation  is  designing  an  HLL  machine  for  the  language  PASCAL  and  Intel 
Corporation  is  designing  its  1APx432  chip  set  that  will  accommodate  a  subset 
of  the  language  Ada.  The  Space  Division  of  the  Air  Force  Systems  Command, 
jointly  with  the  Aerospace  Corporation,  hosted  a  workshop  on  high- level- 
language  computer  architectures  in  Los  Angeles,  October  7-9,  1981.  During  the 
meeting,  IBM's  Yorktown  Research  Laboratory  and  the  Fairchild  Semiconductor 
Corporation  both  expressed  interest  in  such  novel  architectures. 

Clearly,  HLL  machines  and  their  special  architectures  must  be  an  item  of 
interest  for  the  Department  of  Defense.  However,  there  are  technical 
uncertainties  which  must  be  overcome  before  such  machines  will  become  a 
practical  reality.  Until  research  presently  underway  resolves  these 
uncertainties,  it  would  be  unwise  to  delay  acquisition  programs  with  the 
expectation  that  an  HLL  machine  could  be  part  of  the  development  process. 
Furthermore  the  appropriateness  and  payoff  from  such  machines  is  not  yet 
solidly  established;  thus  is  is  inappropriate  for  the  DoD  to  panic  for  a  huge 
research  activity.  However,  it  is  quite  appropriate  for  all  of  the  Services 
to  be  actively  involved  in  the  HLL  research  area  as  one  aspect  of  general 
exploration  of  new  architectures  for  future  machines. 

Some  of  the  present  Industrial  activity  has  been  stimulated  by  the  DoD 
adoption  of  Ada,  and  some  work  is  directly  or  indirectly  supported  by  military 
funding.  However,  the  community  of  research  is  not  large  and  continuing 
support  and  growth  is  obviously  desirable.  HLL  machines  will  undoubtedly  be  a 
significant  step  in  new  computer  architectures.  The  DoD  must  be  properly 
Informed  about  them  so  that  appropriate  choices  and  decisions  can  be  made  in 
acquisition  of  new  weapon  systems,  or  in  retrofits  of  computer-based 
capabilities  to  older  ones. 
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4.3  Proprietary  Data  Rights  as  Affecting  ISA  and  Hardware  Selection 


4.3.1  General 

In  considering  the  major  issues  discussed  in  Chapter  5,  It  became  clear 
that  an  important  factor  was  the  feasibility  of  the  Government's  obtaining 
legal  rights  to  use  an  ISA  not  in  the  public  domain.  A  definitive  resolution 
of  this  concern  was  not  possible.  However,  the  underlying  and  controlling 
issues  will  be  discussed  in  this  Section,  including  the  effect  of  proprietary 
data  as  it  Impacts  upon  management  of  embedded  computer  resources. 


4.3.2  Legal  Techniques  For  Protecting  ISA's 

This  section  will  discuss  legal  protection  techniques  applicable  to 
ISA's,  aspects  of  DoD  use  of  a  commercial  ISA,  and  considerations  of  data 
rights  in  hardware  acquisition  strategies. 

There  are  three  legal  techniques  which  are  generally  used  to  protect  a 
company's  proprietary  ISA  from  its  competitors  and  others: 

1.  Patents, 

2.  Copyrights  and 

3.  Trade  secrets. 


4. 3. 2.1  Patents 

Patents  protect  a  patented  item  against  any  unauthorized  manufacture, 
use,  or  sale  of  the  patented  item.  This  protection  is  broader  than  that  of  a 
copyright  since  it  generally  protects  the  item  even  if  others  have 
independently  developed  the  same  item.  The  Government  (including  contractors 
producing  items  for  it)  cannot  be  prevented  from  manufacturing  or  using  a 
patented  item;  however  the  Government  may  have  to  pay  a  reasonable  price  for 
using  such  a  patented  item. 


4. 3. 2. 2  Copyrights 

Copyrights  protect  an  item  only  against  direct  copying  of  the  item.  They 
do  not  protect  against  an  independent  development  or  creation  of  the  same 
item.  Copyrights  do  not  protect  ideas  —  they  merely  protect  a.  cem  from 
direct  (or  substantial)  copying.  Just  as  in  patents.  Government  contractors 
cannot  be  prevented  from  copying,  however  the  Government  may  have  to  pay  a 
reasonable  price  for  copying  of  copyrighted  items.  It  should  be  noted  that 
the  degree  of  protection  afforded  to  ISA's  through  the  mechanism  of  copyrights 
has  not  been  tested  in  the  courts.  However,  the  courts  have  established  that 
when  a  particular  ISA  (or  a  portion  of  it)  is  Implemented  in  the  form  of  a 
semiconductor  chip,  and  the  pattern  for  that  chip  is  copyrighted,  then  that 
chip  may  not  be  copied. 


4. 3. 2. 3  Trade  Secrets 


"Trade  secrets"  are  a  legal  form  of  protection  which  prevent  unauthorized 
use  of  proprietary  information  which  has  been  kept  secret.  Trade  secret  law 
does  not  prevent  "reverse  engineering"  or  independent  development  of  the 
■proprietary"  information.  Unlike  patents  and  copyrights,  trade  secrets  must 
not  be  freely  disclosed,  and  such  trade  secrets  are  generally  not  available  to 
the  public  or  Government  except  under  conditions  limiting  disclosure  by  the 
recipient.  Acquisition  and  protection  of  trade  secrets  is  extremely 
complicated,  is  dependent  upon  state  law,  and  is  generally  handled  on  a  case 
by  case  basis. 

The  effectiveness  and  extent  of  protection  of  the  above  techniques 
depends  upon  many  complex  legal  and  technical  factors.  These  considerations 
are  important  to  ECR  acquisition  and  management  because  they  further 
complicate  an  already  complex  area  of  rapidly  evolving  technology. 

DoD  Utilization  Of  A  Commercial  ISA 


An  ISA  forms  the  key  link  between  the  support  software  and  the  target 
computer.  Computer  programs  written  and  compiled  for  one  target  computer 
cannot  be  used  on  another  computer  with  a  different  ISA,  unless  the  ISA  of  the 
second  computer  is  related  to  that  of  the  first  in  a  special  way,  or  unless 
the  second  computer  is  arranged  specifically  to  emulate  the  first. 

For  a  commercial  ISA  to  be  desirable  for  the  DoD  to  utilize,  it  should  be 
in  wide  use  and  have  a  rich  support  software  base.  The  owners  of  any  such 
commercially  successful  ISA  protect  both  the  ISA  and  software  from  competitors 
by  one  or  more  of  the  legal  protection  techniques  discussed  above.  However, 
the  legal  protection  available  to  owners  is  not  iron-clad,  and  unlicensed 
second-sources  are  not  an  unknown  phenomenon  in  the  commercial  computer 
software  and  hardware  fields. 

i 

The  Government  must  then  license  an  ISA  or  develop  its  own  if  it  is  to 
reap  advantages  of  commonality  among  computers  utilized  on  the  battlefield  or 
at  sea,  and  to  achieve  maximum  operational  redundancy  by  having  the  capability 
to  run  programs  on  any  available  computer. 

At  present,  it  appears  that  the  commercial  market  share  and  demand  for 
computers  vastly  exceed  the  perceived  needs  of  the  DoD.  Therefore  computer 
manufacturers  generally  find  it  economically  unattractive  to  cater  to  the 
DoD's  needs.  Companies  which  have  useful  and  valuable  ISA's  simply  choose  to 
pursue  the  profitable  commercial  market  and  are  reluctant  to  enter  into 
arrangements  with  the  DoD  which  could  result  in  disclosure  of  trade  secrets  or 
in  ultimate  market  share  competition  with  their  own  commercial  line. 


Page  34 


Given  this  perspective,  it  is  not  surprising  that  the  Army  found  it 
virtually  impossible  to  license  a  commercial  ISA.  Even  agreement  upon  . ne  most 
basic  and  fundamental  definitions  are  extremely  difficult.  The  first 
difficult  definition  is  the  ISA  itself.  Other  examples  of  definitions  which 
proved  difficult  in  specific  negotiations  are: 

1.  Software  identical, 

2.  Software  compatible, 

3.  Bat+ tefield  environment, 

4.  Royalty-bearing  equipment, 

5.  Militarized  (vis  a  vis  ruggedized  commercial)  equipment, 

6.  Computer  software, 

7.  Utility  software, 

8.  Proprietary  data. 

The  bounds  of  the  government's  use  of  the  ISA  must  be  precisely  defined 
Any  company  whose  ISA  is  chosen  will  also  want  to  sell  the  government  its 
commercial  equipment  and  not  see  that  market  negatively  impacted  by  military 
equipment  using  that  ISA.  To  protect  its  patents  and  trade  secrets,  the 
licensor  may  need  to  inspect  other  companies'  manufacturing  facilities  and 
hence  those  companies'  trade  secrets  would  be  in  jeopardy.  The  licensor  may 
negotiate  to  approve  which  companies  receive  RFP's  or  approve  the  contractors 
selected  by  the  government  to  manufacture  hardware.  It  may  also  make  the 
license  contingent  upon  approval  of  its  other  licensees,  etc.  There  are 
countless  other  factors  such  as  agreements  to  standardize  in  NATO  for 
interchangeability  and  survivability  which  the  government  would  have  to 
negotiate  with  the  licensor.  The  Task  Force  reviewed  one  check  list  for 
patent  negotiations  which  was  12  pages  long. 

The  NEBULA  ISA  was  developed  under  Army  contract  (DAAK80-79-C-0767 )  by 
Carnegie-Mellon  University  and  unlimited  rights  in  data  were  acquired  by  the 
Army.  While  no  mechanism  exists  to  preclude  any  patent  holder  from  bringing 
suit  related  to  the  NEBULA  ISA,  we  know  of  no  patents  infringed  by  the  NEBULA 
ISA.  Even  if  valid  patents  are  infringed.  Government  contractors  could  not  be 
prevented  from  selling  to  the  Government,  but  the  Government  would  be  liable 
for  a  reasonable  royalty.  Commercial  sale,  however,  could  be  prevented  unless 
necessary  royalties  were  negotiated. 

It  is  noteworthy  that  the  Army  has  no  objection  to  its  MCF  contractors 
marketing  commercial  implementations  of  the  NEBULA  ISA.  Such  action  by  MCF 
contractors  would  broaden  the  base  of  NEBULA;  it  would  create  knowledgeable 
talent  for  the  government  to  draw  upon,  would  promote  the  generation  of  a 
large  base  of  NEBULA  compatible  Ada  programs  and  would  create  incentive  for 
those  contractors  to  continue  development  of  the  ISA  to  increase  its  value  and 
provide  a  broad  base  of  knowledgeable  contractors  for  future  competition. 


Page  35 


Because  of  its  perception  of  the  desirability  of  commercial  implementation  of 
the  NEBULA  architecture,  the  government  made  its  best  efforts  to  obtain  a 
design  which  would  not  infringe  known  patents^1 . 


4*3. 2. 4  Nota  Bene 

One  of  the  Task  Force  Members  [GHH]  offered  the  following  additional 
observation  and  recommendation: 


"The  commercial  availability  of  32-bit  architectures  in  single 
chip  form  from  several  semiconductor  companies  represents  a 
discontinuity  that  should  be  strongly  considered  by  the  DoD.  In 
contrast  to  computer  companies  that  have  a  vested  interest  in 
maintaining  proprietary  architectures,  semiconductor  companies  benefit 
from  offering  their  architectures,  already  in  single-chip  form,  to 
everyone.  Furthermore,  each  semiconductor  company  has  multiple 
sources  for  their  chip,  thus  ensuring  the  competition  will  result  in 
lower  costs  to  the  DoD.  It  is  recommended  that  the  DoD  explore  the 
adoption  of  one  of  the  existing  large  address  space  architectures 
already  available  in  single  chip  form  from  several  semiconductor 
companies,  each  with  multiple  sources  of  supply." 


The  Task  Force  did  not  discuss  this  specific  issue  in  detail?  it  is  included 
here  for  sake  of  completeness  and  for  the  appropriate  further  consideration  of 
the  DoD. 

Data  Rights  In  ECR  Hardware  Acquisitions 

Data  rights  come  into  play  not  only  with  regard  to  development  and  use  of 
an  ISA,  but  in  the  acquisition  of  hardware  as  well.  For  instance,  in  the  MCF 
program,  even  though  the  Government-owned  NEBULA  ISA  has  been  specified,  the 
four  Advanced  Development  contractors  are  completely  free  to  design  and 
utilize  hardware  implementations  which  reflect  and  incorporate  the  best 
technology  that  the  contractor  considers  appropriate  for  the  given 
application — to  design  for  cost,  reliability,  survivability  and  other  design 
considerations . 

There  is  no  problem  in  incorporating  the  latest  in  technology  into  ECR 
systems,  but  in  so  doing  the  contractor  is  likely  to  utilize  company  developed 


1  During  the  presentation  of  the  findings  and  recommendations  of  the  Task 
Force  to  the  full  Defense  Science  Board,  the  DSB  indicated  their  strong 
feeling  that  there  may  yet  be  an  acceptable  approach  for  including  "commercial 
ISAs"  on  the  DoD-approved  list  while  maintaining  an  open  and  equitable 
competitive  environment.  Past  failures  in  this  endeavor  were  not  considered 
by  the  Board  to  be  sufficient  reason  to  discontinue  efforts  toward  this 
objective.  DoD  promised  to  take  the  lead  in  initiating  further  discussion 
with  industry,  likely  via  one  of  the  Associations. 
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trade-secret  or  patented  technology.  This  presents  obvious  difficulty  in  then 
attempting  to  establish  a  second  source  for  reprocurement  or  because  the 
original  source  has  either  gone  out  of  business  or  has  simply  decided  not  to 
continue  to  manufacturer  or  support  the  item.  However,  these  problems  and 
obstacles  to  second  sourcing  can  be  minimized  if  careful  attention  is  paid  to 
the  acquisition  strategy  and  contracting  methodology  at  least  before  the 
advanced  development  phase  begins. 
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5.  MAJOR  ISSUES,  DISCUSSION  AND  RECOMMENDATIONS 

5.1  On  Proceeding  with  DoD  Instruction  5000. 5x 


5.1.1  Discussion 

DoD  Instruction  5000. 5x  is  the  proposed  Department  of  Defense  Instruction 
which,  upon  Issuance,  would  establish  the  DoD  policy  for  embedded  computer 
Instruction  Set  Architecture  selection. 

The  principal  elements  of  the  policy  defined  by  the  proposed  Instruction 

are: 


-  Only  DoD-approved  ISAs  may  be  used  in  defense  systems  unless  it  is 
demonstrated  that  none  of  the  approved  ISAs  are  practical  or  cost- 
effective. 

-  Each  DoD-approved  ISA  is  to  be  assigned  to  a  Service  to  ensure  its 
stability  of  specification  and  configuration  management. 

-  Approved  ISAs  shall  be  reviewed  at  least  every  two  y;ars. 

-  Each  DoD  Component  shall  initiate  procedures  to  grant  or  reject 
waivers  to  this  policy. 

This  Instruction  covers  all  embedded  digital  computers  and  processors, 
regardless  of  Implementation,  technology  or  size,  unless  they  are  specifically 
excluded  by  the  paragraphs  below: 

-  Nonmllitarized,  general-purpose,  coramercially-available  stand-alone 
computers. 

-  Digital  computers  and  processors  used  in  hardware  intensive-^ 
applications . 

-  Digital  computers  and  processors  utilized  as  part  of  Automatic  Test 
Equipment  (ATE)  and  Crew  Training  Devices  (CTD). 

-  Certain  commercial  products  which  contain  non-militarized  computers 
such  as  Instruments,  materials  handling  systems,  etc. 


^By  hardware  intensive  we  mean  those  computer  applications  in  which  the 
function  to  be  performed  is  fixed,  hence  the  computer  program  (software)  is 
not  expected  to  be  changed  for  the  lifetime  of  the  physical  component  in  which 
it  is  embedded. 
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The  status  of  this  proposed  policy  is  that  it  has  received  formal  review 
from  each  of  the  Military  Departments,  the  cognizant  OSD  staff  offices  and 
industry  but  it  has  not  yet  been  issued  by  the  Under  Secretary  of  of  Defense 
(Research  and  Engineering).  A  principal  motivation  for  establishment  of  the 
Task  Force  was  lack  of  consensus  on  DoDI  5000. 5x  both  within  the  Department 
and  the  affected  industrial  community.  Future  embedded  computer  acquisition 
programs  of  each  of  the  Military  Departments  are  heavily  influenced  by  this 
Instruction.  Hence,  there  is  properly  a  wide  interest  in  the  appropriateness 
of  this  Instruction.  The  other  conclusions  and  recommendations  of  the  Task 
Force  pivot  strongly  on  the  resolution  of  this  issue  so  a  major  portion  of  the 
Task  Force's  time  was  spent  in  reaching  our  position  on  5000. 5x. 


The  Military  Departments  favor  issuance  of  the  Instruction  because  it 
eases  the  management  problems  associated  with  system  development  and,  more 
importantly,  limiting  the  number  of  ISAs  is  seen  as  ameliorating  the  growing 
Post  Deployment  Software  Support  (PDSS)  problems  of  cost  and  manpower  through 
the  rest  of  this  century.  The  Army  views  5000. 5x  as  a  necessary  fundamental 
step  in  its  efforts  to  achieve  battlefield  survivability. 


Each  of  the  Military  Departments,  on  its  own,  has  issued  policy  which 
closely  follows  the  guidance  of  5000. 5x.  Failure  to  issue  the  Instruction 
will  be  taken  as  a  repudiation  of  both  the  Instruction  and  the  supporting 
Service  policies. 

DoDI  5000. 5x  is  only  a  portion  of  the  defining  regulatory  instructions 
for  DoD  computer  acquisition.  DoDI  5000. 5x  responds  to  the  unique 
requirements  of  the  Military  Departments  to  support  and  maintain  forces  and 
equipment  in  the  field  under  battlefield  conditions.  This  requirement  applies 
to  equipment  over  a  lifetime  of  several  decades.  It  is  a  portion  of  the  broad 
view  taken  of  the  computer  resource  acquisition  process  under  the  Warner 
language  of  Section  908  of  the  FY1982  Defense  Authorization  Act.  This  recent 
legislative  language  provides  the  new  criterion  of  Mission  Functionality  as  a 
determinant  of  computer  resource  acquisition  methods.  DoDI  5000. 5x  clearly 
does  not  apply  to  those  data  processing  systems  acquired  under  traditional 
Brooks  Act  procedures.  The  detailed  language  of  5000. 5x  needs  to  be  reviewed 
for  consistency  with  current  acquisition  policy  before  it  is  officially 
issued. 

DoDI  5000. 5x  policies  will,  through  time  after  issuance,  change  the 
development  and  acquisition  practices  of  the  Department.  In  the  transition 
period,  the  waiver  process  will  serve  as  a  buffer  mechanism  to  smooth  over 
difficulties.  Sensitive  handling  of  waivers,  in  close  coordination  with  the 
acquisition  process,  is  required  to  balance  competing  forces  of  genuine  and 
sometimes  painful  progress  toward  standardization  and  avoidance  of  paralysis 
induced  by  emerging,  yet  Incomplete,  standard  achievements. 

The  arguments  in  favor  of  DoDI  5000. 5x  are  based  on  the  following 
important  considerations: 


-  Battlefield  Survivability  achieved  by  computer-based  systems  which 
can  substitute  for  each  other  at  a  direct  ISA  level  to  maintain 
capability  despite  battle  damage. 
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-  Logistic  Supportabi 11 ty  in  the  dynamic  environment  of  battle, 
achieved  by  cannibalization  or  adequate  logistic  sparing  permitted 
by  the  reduced  number  of  types  of  equipments. 

-  Economic  Feasibility  to  Logistically  Spare  due  to  the  reduced  number 
of  types  of  deployed  embedded  computers. 

-  Substantial  Cost  Avoidance  over  a  time  frame  of  several  decades  due 
to  the  availability  to  use  in  common  applications  and  utility 
support  software  developed  for  a  limited  number  of  permitted  ISAs. 

-  Greatly  Reduced  Software  and  Hardware  Personnel  Needs  due  to  the 
economy  of  scale  and  not  having  to  provide  for  several  decades  the 
very  many  specially  trained  people  required  for  the  present 
proliferation  of  embedded  computer  equipment. 

The  arguments  of  those  who  oppose  this  proposed  policy  center  on  the  idea 

that: 


"Standardization  will  stultify  the  introduction  of  new  technology 
and  that  it  will  negatively  affect  competition  and  hence  gradually 
increase  DoD  costs." 

There  is  also  wide-spread  belief  that  commercial  computer  technology  is 
changing  so  fast  that  restriction  to  a  limited  number  of  ISAs  will  preclude 
DoD's  use  of  the  best  U.S  computer  technology.  There  is  also  a  belief  that  it 
is  not  possible  to  fix  a  list  of  ISAs  now  for  application  a  long  time  into  the 
future  since  new  developments  may  well  obsolete  them. 


The  crux  of  the  resistance  seems  to  be  that  the  specific  effect  of  this 
new  policy  on  traditional  market  share  and  business  practice  is  not  easily 
forecast.  That  is  to  say#  the  policy  injects  a  new  risk  parameter  into 
business  and  marketing  strategy.  For  most  militarized  computer  acquisitions 
in  the  past,  once  a  design  (hence  supplier)  was  chosen  for  a  major  system,  it 
was  nearly  impossible  to  find  alternate  sources  for  follow-on  production. 
Nearly  every  militarized  computer  included  proprietary  design  features  so 
that,  when  actually  possible  to  establish  second  sources  for  mobilization  and 
economic  cons i derations,  it  is  only  with  the  sufferance  of  the  principal 
supplier.  Furthermore,  the  support  equipment  often  had  to  be  maintained  long 
after  the  commercial  world  had  moved  on  to  other  systems. 


^9  5.1.2  Findings 

On  balance,  the  DSB  Task  Force  finds  the  arguments  in  favor  of 
■\  restricting  the  number  of  ISAs  to  be  compelling.  Insertion  of  new  technology 

into  Military  Department  implementations  is  believed  by  the  Task  Force  to  be 
V  quite  possible  under  DoDI  5000. 5x  and  a  proper  implementation  of  the  policy 

^  can  be  monitored  to  ensure  technology  insertion. 
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The  Task  Force  recognizes  the  importance  of  competition  in  procurement  which, 
it  appears,  can  be  suitably  achieved  under  DoDl  5000. 5x.  In  general,  direct 
application  of  commercial  equipments  as  embedded  computers  will  be  difficult 
due  to  the  need  for  these  equipments  to  meet  environmental  requirements  of  the 
military  application.  However,  the  adoption  of  emerging  commercial  techniques 
into  equipment  designed  to  5000. 5x  ISAs  should  not  present  any  unusual 
problems.  The  Task  Force  believes  that  emerging  development  in  components 
(e.g.,  VHSIC )  or  computer  organization  (e.g.,  array  processors)  can  be 
advantageously  included  in  equipments  based  on  the  ISA  policy  of  5000. 5x. 

The  policy,  as  written,  offers  adequate  opportunity  for  waiver  when 
conformance  to  the  policy  is  not  warranted.  The  policy  also  offers  adequate 
opportunity  for  expansion  of  the  approved  list  of  authorized  ISAs,  if  and  when 
necessary,  to  respond  to  emerging  technology.  It  also  offers  the  opportunity 
for  reduction  in  numbers  of  ISAs  as  the  Military  Departments  converge  their 
approaches  to  next-generation  ISAs . 


5.1.3  Recommendations 

! 

Our  recommendation  is  to  issue  the  Instruction  and,  through  other  actions 
as  noted,  to  produce  a_  context  in  which  the  potential  benefits  of  ISA 
standardization  will  be  realized  by  the  DoD.  Any  new  standard  provides 
opportunities  for  misuse.  This  Instruction,  if  properly  implemented,  has 
adequate  provisions  to  avoid  misuse  and  is  a  necessary,  but  not  sufficient, 
part  of  the  total  standardization  and  coordination  efforts  required  in  OSD. 

Before  issue,  the  language  of  DoD I  5000. 5x  should  be  reviewed  for 
consistency  and  clarity  in  the  context  of  the  recent  Warner  language  of 
Section  908  of  Public  Law  97-86.  In  particular,  the  delineation  of  which 
defense  systems  will  fall  under  the  provisions  of  DoDl  5000. 5x  policy  needs 
clarification  as  does  the  matter  of  which  system  are  exempt.  A  system  might 
use  a  non-5000.5x  ISA  either  because  5000. 5x  does  not  apply  to  its  mission  or, 
if  5000. 5x  does  apply,  because  the  system  falls  into  one  of  the  specific 
exemption  categories  listed  in  5000. 5x.  The  version  of  5000. 5x  issued  must  be 
clear  on  the  issues  of  applicability,  exemption  and  authority  in  the  current 
acquisition  environment. 


Exemptions  from  DoDl  5000. 5x  under  the  hardware-intensive  cat 


deserve  very  careful  consideration.  The  ubiquity  of  microprocessors  in  large 
quantity  in  DoD  applications  is  inevitable.  While  the  software  content  in 
each  hardware-intensive  application  may  be  small,  the  multiplier  over  all  DoD 
on  this  software  can  produce  a  large  expenditure.  We  recommend  that  the 
Military  Departments,  with  OSD  review,  define  criteria  appropriate  to  their 
needs  for  the  hardware-intensive  exemption  category  with  emphasis  on  software 
lifetime  support  as  opposed  to  any  hardware  characteristics.  A  decade  of 
reprogramming  after  acquisition  is  expensive  whether  for  a  mainframe  or  any 
kind  of  microprocessor-based  system  component,  no  matter  how  small.  Since 
5000. 5x  is  intended  to  help  contain  life-cycle  software  support  costs, 
hardware-intensive  exemptions  should  be  limited  to  applications  with  small 
expected  continuing  software  support  requirements. 
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Once  a  list  of  standard  ISAs  is  official  through  Issuance  of  DoDI 
5000. 5x,  Its  current  appropriateness  must  be  closely  monitored .  OSD  should 
develop  criteria  for  adding  and  especially  for  deleting  entries  on  the  list 
and  should  monitor  waiver  actions  for  early  notice  of  technical  trends  which 
indicate  needed  changes.  OSD  should  annually  review  the  Departmental  actions 
implementing  5000. 5x.  DoD-sponsored  work  leading  to  new  ISAs  should  be 
planned  coherently  and  coordinated  in  execution. 


We  recommend  appropriate  attention  to  follow-on  steps  which  will  be 
possible  because  of  5000. 5x.  For  example,  one  reason  for  issuing  DoDI  5000. 5x 
is  to  facilitate  battlefield  survivability.  This  Instruction  provides  the 
authority  for  a  common  ISA  in  battlefield  situations  which,  in  turn,  could 
permit  exchange  of  tactical  [object  code]  software  from  damaged  into  working 
equipment.  However,  many  further  actions  are  required  to  achieve  this 
capability  in  fact.  The  need  for  software  exchange  must  be  formally  included 
in  requirements,  designed  into  the  field  systems,  and  then  validated  in  the 
T&E  phase  of  development.  If  appropriate  follow-up  actions  are  not  taken  and 
adequate  resources  not  provided,  issuing  DoDI  5000. 5x  will  be  an  exercise  in 
bureaucratic  futility  with  respect  to  life-cycle  cost  containment. 


5.2  On  Implementation  of  Proposed  DoDI  5000. 5x 


5.2.1  Discussion 

As  noted  in  Subsection  5.1.1,  each  of  the  Services  has  already  found  it 
desirable  to  initiate  programs  to  restrict  the  number  of  ISAs  used  in  their 
embedded  computer  systems.  The  Army's  Military  Computer  Family  (MCF)  based  on 
the  NEBULA  ISA  is  described  in  Section  3.2.  The  Navy's  Embedded  Computer 
System  (NECS)  is  described  in  Section  3.3.  The  Air  Force  approach  based  on 
MIL-STD-1750  is  described  in  Section  3.4.  Each  of  the  Services  plans  to  base 
its  implementation  of  DoDI  5000. 5X  on  its  current  program.  Therefore,  the  Task 
Force  reviewed  these  programs  in  some  detail  to  judge  the  reasonableness  of 
the  approaches  and  to  consider  possible  changes  to  them. 

Each  of  the  programs  was  reviewed  with  respect  to  the  factors  discussed 
in  Section  5.1.1  which  were  found  to  affect  the  desirability  of  limiting  the 
number  of  ISA's.  For  all  Services,  the  dominant  concern  in  implementing 
5000. 5x  is  to  maximize  their  probability  of  meeting  mission  requirements  and, 
thus,  maximize  their  war-fighting  capability.  In  general,  each  of  the 
Services  has  found  that  the  advantages  summarized  in  Section  5.1.1  do  apply, 
e.g.,  substantial  reductions  in  support  software  costs  have  resulted  or  are 
fully  expected  to  result.  However,  the  relative  importance  of  these  factors 
varies  substantially  across  the  Services.  By  standardizing  on  an  ISA,  each 
Service  has  the  capability  to  reduce  its  continuing  software  support  cost. 

This  is  possible  by  reducing  the  number  of  software  support  systems  and  the 
amount  of  support  software  which  must  be  created  for  each  ISA.  This  is  not 
unlike  the  approach  Industry  has  followed.  Further,  the  resulting  savings  from 
reducing  unnecessary  software  proliferation  can  be  applied  to  the  necessary 
software  development  and  support  systems,  increasing  productivity  and 
transportability.  This  is  viewed  as  a  major  step  toward  the  long-range  goal  of 


reducing  future  costs  of  software  development  and  support.  The  expected  cost 
avoidance  cannot  be  easily  quantified,  but  is  thought  to  be  sizeable.  Some 
statements  to  the  Task  Force  would  estimate  these  costs  in  hundreds  of 
millions  of  dollars. 

Survivability  on  the  battlefield,  at  sea,  and  in  the  air  is  greatly 
enhanced  with  interchangeability  of  computers  for  automated  systems.  Each 
Service  has  a  variety  of  applications  for  embedded  computers.  Although 
acquisition  strategies  for  implementations  (hardware)  vary  depending  on  the 
application,  standardizing  on  an  ISA  will  facilitate  interchange  equipment  in 
critical  situations. 


The  Air  Force  acquisition  strategy  for  implementation  of  MIL-STD-1750A 
takes  advantage  of  the  most  important  factors  for  the  Air  Force.  With  each  new 
aircraft,  the  most  important  factor  is  reduced  cost  and  time  required  for 
system  development  due  to  the  complete  software  support  environment  which  is 
available  to  the  program  manager  for  MIL-STD-1750A. 


The  Navy  acquisition  strategy  for  the  AN/UYK-43  and  -44  is  almost 
identical  to  the  Army’s  tor  the  Military  Computer  Family,  yet  it  is  tailored 
for  the  specific  needs  of  the  Service  and  its  environment.  The  Navy  has  a 
sizeable  investment  in  software  and  is  acquiring  the  43  and  44  with  extensions 
to  the  AN/UYK-7  and  -20  ISA’s  to  capture  its  software  investment.  Early 
success  in  this  program  proves  that  ISA's  can  maintain  upward  compatibility 
and  new  technology  can  be  Inserted.  For  the  Navy  program,  the  most  important 
consideration  is  the  substantial  savings  which  result  from  reduced  sparing 
required  to  achieve  the  required  operational  availability.  A  simple  model 
estimated  $30,000,000  cost  avoided  per  computer  type  by  not  placing  different 
hardware  Implementations  of  the  same  or  different  ISAs  aboard  ship.  Increased 
operational  availability  is  achieved  due  to  sparing  as  the  number  of  identical 
copies  of  hardware  is  increased. 


The  Army  currently  has  a  large  number  of  computer  types  either  fielded, 
in  production,  or  in  development  — some  55  distinct  types  in  62  specific 
systems.  This  proliferation  of  computers  increases  development,  production, 
maintenance,  and  training  costs  while  reducing  survivability.  The  major 
advantage  of  standardization  for  the  Army  is  increased  survivability  on  the 
battlefield  through  Interchangeability  and  cannibalization  of  computers,  while 
benefiting  from  increased  operational  availability,  as  in  the  Navy's  case.  The 
Army  will  also  benefit  from  reducing  the  number  of  computer  types  in  logistics 
channels.  Not  including  benefits  from  maintenance  training,  reliability, 
system  software  development,  or  post  deployment  software  support,  an 
unvalidated,  but  conservative,  cost-avoidance  estimate  is  $500,000,000  by  1992 
with  the  Military  Computer  Family  Program  as  compared  to  continued 
proliferation  of  computer  types. 

Quantitative  data  available  to  the  Task  Force  was  weak.  Economic  studies 
are  inherently  suspect  because  they  must  use  assumptions  about  projected 
requirements,  projected  costs,  and  "straw-man”  alternative  programs.  However, 
the  Navy  and  Air  Force  experience  that  common  support  programs  are  really 
being  used  across  many  systems  and  the  Navy  experience  that  a  restricted 
number  of  ISA's  really  are  advantageous  on  shipboard  serve  to  reinforce  the 
economic  studies  and  qualitative  arguments. 
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The  Task  Force  reviewed  the  approach  being  used  on  the  Army's  Military 
Computer  Family  (MCF)  program  which  uses  an  ISA  (NEBULA)  designed  within  the 
program  rather  than  a  commercial  ISA  for  which  rights  would  need  to  be 
purchased.  In  theory,  the  use  of  a  commercial  ISA  might  provide  two  main 
advantages: 


1.  The  ISA  would  have  been  implemented  commercially  and  tested  :n  many 
installations  so  that  a  minimum  shake-out  period  would  be  required. 

2.  A  large  body  of  software  would  exist  and,  thus,  development  cost 
and  time  could  be  avoided. 

Major  disadvantages  of  standardizing  a  commercial  ISA  include: 


1.  All  valuable  commercial  ISA's  and  support  software  for  them  are 
protected  by  patents,  copyrights,  or  as  trade-secrets  (or  a 
combination  of  protections).  Negotiations  for  any  particular  ISA 
must  include  definitions  of  terms  which  are  extremely  difficult  and 
time  consuming  to  resolve  such  as:  software  identical,  software 
compatible,  royalty  bearing  equipment,  utility  bearing  equipment, 
etc.  Other  items  such  as  rights  of  other  contractors,  where  the 
equipment  will  be  used,  governing  law,  disposition  of  equipment, 
positions  of  other  existing  licensees,  must  be  negotiated.  Army's 
experience  indicates  that  it  is  very  difficult  if  not  impossible, 
to  acquire  the  rights  without  many  restrictions  even  if  there  is  no 
royalty  involved. 

2.  Changes  to  the  ISA  and/or  the  support  software  over  a  period  of 
time  are  not  under  control  of  the  government.  This  leaves  continued 
support  of  the  ISA  dependent  on  commercial  success. 

3.  Efforts  to  evaluate  one  ISA  over  another  are  extremely  time 
consuming,  imprecise  and  somewhat  subject  to  its  implementation  in 
hardware  rather  than  on  the  merit  of  the  ISA  alone. 

4.  Since  ISA's  are  valuable  to  the  owner  and  therefore  protected, 
choice  of  a  commercial  ISA  for  DOD  or  a  service  will  be  an  economic 
bonanza  for  the  company  whose  ISA  is  chosen.  Competition  is  seen 
being  limited  in  the  long  term,  due  to  the  so3e-source  nature  of 
the  licensing  process. 

After  lengthy  discussion,  the  Task  Force  concluded  that  neither  the 
economics  nor  the  availability  of  software  necessarily  favored  use  of  a 
commercial  ISA  and  that  the  technical  risk  associated  with  a  new  ISA  was  not 
great  although  it  could  result  in  some  increase  in  currently-planned 
schedules.  The  value  of  the  support  software  issue  is  ameliorated  by  DoD’s 
work  with  Ada  and  the  fact  that  the  Army's  Ada  Language  System  (ALS)  i6  hosted 
on  a  commercial  machine  which  takes  advantage  commercially-available  software. 
The  ALS  is  required  to  be  re-hostable  to  other  commercial  machines  for 
transportability. 


The  Army  contingency  plan  to  counter  a  significant  schedule  slip,  should 
such  a  slip  occur,  is  to  continue  their  transition  program  making  use  of  a 
subset  of  the  ISA's  and  software  support  systems  currently  planned  to  be 
supported.  New  systems  would  be  started  on  these  until  the  ALS  and  MCF  are 
available.  The  current  policy  and  waiver  process  would  improve  up-front 
planning  and  allow  for  exceptions.  Delays  to  the  ALS  and  MCF  will  delay  the 
availability  of  survivability,  economic,  and  other  benefits  of  MCF,  but  will 
not  significantly  reduce  them. 

After  reviewing  the  Air  Force,  Navy  and  Army  programs,  the  Task  Force 
discussed  the  variations  among  them.  There  are  clearly  differences  in  their 
present  status  which  lead  to  variations.  For  example:  The  Air  Force  has  a  very 
different  maintenance  and  logistic  situation  than  do  the  Army  and  Navy,  and 
the  Navy  has  a  large  existing  software  base  on  just  two  types  of  computers 
while  the  Army  is  faced  with  over  50  different  types  of  computers  in  the 
inventory.  After  discussion  as  to  whether  strong  measures  should  be  taken 
immediately  to  adopt  a  single  ISA  for  all  Services,  we  decided  that  was  not 
practical  at  this  time.  It  may  never  be  practical  to  go  to  a  single  ISA  for 
all  three  Services.  However,  we  believe  that  steps  should  be  taken  to  make  the 
next  generation  as  close  to  "all  Service"  ISAs  as  possible.  A  recommended 
approach  to  achieving  this  is  indicated  in  Section  5.1.3. 


5.2.2  Recommendations 

The  Task  Force  recommends  that  each  of  the  Services  proceed  with  its 
current  program.  However,  we  also  recommend  that  each  of  the  Services  consider 
the  following  changes  in  detail  to  their  plans  and  report  the  conclusions  of 
their  considerations  for  review  by  OSD. 

5. 2. 2.1  Army  and  Navy 

1.  It  is  possible  that  lower  production  costs  can  be  obtained  over  the 
full  production  cycle  if  more  than  one  contractor  can  produce 
produce  logistically-identical  machines,  either  right  from  the 
start  or  after  an  initial  production  period.  Both  the  Army  and  the 
Navy  should  determine  the  front-end  costs  of  possible  arrangements 
for  doing  this  and  estimate  the  overall  costs  or  savings. 

2 .  We  have  concern  that  time  limits  in  procurement  regulations  may 
lead  to  a  development  cycle  that  is  shorter  than  is  desirable  from 
technological  considerations.  OSD  should  determine  whether  changes 
in  the  Defense  Acquisition  Regulations  (PAR)  must  be  requested  to 
provide  the  necessary  flexibility  in  timing  of  new  development 


5. 2. 2. 2  Army 

Increase  the  number  of  prototype  NEBULA  machines  to  be  available  at  an 
early  date  for  advanced  development  by  projects  planning  the  use  of  MCF  soon 
after  its  availability. 
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5. 2. 2. 3  Air  Force 

It  is  clear  that  the  trade-offs  for  different  implementations  of  MIL- 
STD-1750A  are  likely  to  make  it  desirable  to  have  more  than  one 
implementation.  However,  Army  and  Navy  studies  indicate  that  the  logistic 
savings  may  be  substantial  for  each  different  implementation  that  is 
eliminated. 


1.  The  Air  Foiv:a  should  consider  bounding  the  number  of  unique 
implementations  of  MIL-STD-1750  with  an  eye  toward  achieving 
logistic  cost  avoidance. 

2.  The  Air  Force  should  consider  the  possible  advantages  of  adding  1/0 
specifications  to  MIL- STD- 17 50 A. 


/ 


"  •- 
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5.3  On  Implementation  of  DoDI  5000.31 


5.3.1  Discussion 

The  intent  of  DoD  Instruction  5000.31  is  to  encourage  the  use  of  High 
Order  Languages  (HOLs)  in  defense  applications  and  to  limit  the  number  of  HOLs 
used  to  a  small  set  with  eventual  convergence  to  a  minimum  (one).  There  is 
very  little  controversy  over  this  policy.  It  has  been  in  effect  since 
November,  1976,  and  few,  if  any,  negative  effects  have  been  noticed. 

The  proposed  revision  to  this  Instruction  has  been  prepared  which 
reaffirms  DoD's  commitment: 


1 .  To  reducing  the  number  of  programming  languages  used  in  military 
systems, 

2.  To  minimizing  use  of  machine-oriented  (assembly)  languages,  and 

3.  To  transition  to  modern,  machine-independent  languages. 

The  revision  also  discusses  Ada,  to  wit: 

"Ada  is  intended  to  be  the  common,  machine-independent,  embedded 
computer  system  programming  language  for  DoD-wide  use.  Individual  DoD 
Components  shall  not  Implement  a  more  restrictive  policy  which  would 
require  a  waiver  to  use  Ada  within  their  Component." 


While  the  original  issue  of  5000.31  required  an  exception  for  use  of  any 
language  not  on  the  approved  list,  the  revision  is  more  specific.  It  states: 


"A  waiver  must  be  obtained  for  each  Defense  System: 


1.  For  the  use  of  any  High  Order  Language  (HOL)  or  special  purpose 
language  not  listed  ... 

2.  For  use  of  any  Machine  Oriented  Language  (MOL)  as  the  principal 
programming  language  of  the  system,  or 

3.  For  the  use  of  any  extensions  to  or  enhancements  of  an  approved 
language." 

Waivers  are  to  be  Issued  only  when  it  is  demonstrated  that  none  of  the 
approved  HOLs  are  technically  practical  or  cost  effective  over  the  system  life 
cycle. 
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5 . 3 . 1 « 1  Approved  High  Order  languages 

The  HOLs  proposed  for  the  revision  of  DoDI  5000.31  are  as  follows: 

1.  CMS-2M;  "CMS-2M  Computer  Performance  Specifications,"  NAVSEA 
0967LP-598-221 0 ,  October  1978. 

2.  JOV1AL-J73;  Military  Standard  MIL-STD-1 589B  (USAF),  March  15,  1979. 

3.  ANS  FORTRAN-1978;  ANSI  X3-1978;  FIPS  69. 

4.  Ada;  Military  Standard  MIL-STD-1 81 5,  December  198033. 

The  Instruction  also  proposes  to  approve  three  "special  purpose" 
languages  which  may  be  used  in  their  respective  application: 


1 .  Automatic  Test  Equipment  (ATE)  Applications 

-  ANS  ATLAS;  "IEEE  Standard  ATLAS  Test  Language  (Full  ATLAS)," 
ANSI/IEEE  Standard  416-1980. 

-  "Common  ATLAS";  IEEE  Standard  716-1981. 

2.  Signal  Processing  Applications 

-  SPL/1 ;  "SPL/1  Language  Reference  Manual,  5490-163;  NRL, 
Washington ,  DC . 

3.  Business  and  Management  Information  Systems  (MIS)  Applications 

-  ANS  COBOL;  ANSI  X3.23,  1974. 


Implementation  of  DoDI  5000.31  has  been  spotty  and,  at  present,  there  is 
little  motivation  for  any  of  the  Components  to  adopt  existing  languages 
developed  for  use  fcy  others.  The  Army  found  reliance  on  TACPOL  to  be 
inappropriate  and  has  requested  that  it  be  dropped  form  the  list  of  approved 
HOLs.  The  Army  may,  therefore,  use  FORTRAN,  ask  for  an  HOL  waiver  or  use  one 
of  the  other  5000.31  languages.  The  Navy  course  continues  to  be  set  on  the 
use  of  CMS-2  for  the  current  generation  because  of  the  huge  investment  they 
have  in  applications  code.  In  the  case  of  the  Air  Force,  the  interim  standard 
language  is  JOVIAL- J73. 


33  _ 

MIL-STD-1 81 5  is  being  coordinated  as  an  ANSI  Standard  Document  via  the 
canvass  method 


It  appears  that  each  of  the  Military  Departments  is  proceeding  with  DoDl 
5000.31  in  spirit?  however,  for  the  time  being  they  are  on  parallel  rather 
than  converging  paths.  The  first  real  opportunity  for  the  Services  to  move 
form  their  past  course  in  the  direction  of  convergence  is  expected  to 
accompany  the  introduction  of  Ada.  Each  of  the  Services  anticipates  this  and 
appears  to  be  aggressively  planning  accordingly. 

In  the  instance  of  the  Army,  the  MCF  program  incorporates  Ada 
standardization.  In  fact,  the  Army  Ada  Language  System  (ALS)  is  important  to 
DoD's  actual  implementation  of  Ada.  Our  major  concern  here  is  that  the  Army 
Ada  effort  may  be  too  lightly  funded.  In  addition,  strict  adherence  to  rigid 
time  requirements  on  this  schedule-driven  program  may  preclude  some 
opportunities  to  improve  the  eventual  implementation  of  Ada.  Further,  we  have 
concern  over  the  completeness  of  the  support  software  suite.  The  Air  Force 
Ada  program  appears  well  conceived  and  should  complement  the  Army  effort. 


5.3.2  Recommendations 

The  Task  Force  recommends  that  revised  DoD  Instruction  5000.31  be  issued 
basically  as  drafted.  In  that  time  has  passed  since  formal  coordination  of  the 
draft,  it  should  be  reviewed  to  assure  adequate  encouragement  of  the 
introduction  of  Ada.  The  policy  in  the  Instruction  should  be  correlated  with 
the  current  status  of  the  Ada  Program.  The  latest  versions  of  the  defining 
documents  should  be  cited. 

Since  the  success  of  Ada  is  very  important  and  since  that  success  is  not 
yet  assured,  continued  management  attention  should  be  given  to  single-service 
and  multi-service  Ada  development  and  promotion  efforts.  Funding  support  for 
the  introduction  and  development  of  Ada  and  Ada-related  tools  will  be  of 
critical  importance  throughout  the  Program. 

We  recommend  that  encouragement  and  funding  be  provided  to  the  Navy  to 
facilitate  and  expedi te  transition  to  Ada .  This  may  include  development  of 
code  conversion  aids  and  multi-language  support  tools  for  interim  use. 

We  recommend  that  the  Army  Ada  Program  be  reviewed  to  assure: 

1 .  That  funding  is  adequate, 

2.  That  schedule  requirements  are  not  overly  ambitious, 

3.  That  schedule  requirements  do  not  prematurely  preclude  benefits 
derived  from  slightly  greater  language/environment  maturity  and 

4.  That  the  support  software  suite  is  comprehensive. 

We  recommend  that  OSD,  together  with  the  Air  Force,  review  the 
rtunities  for  cost  savings  within  the  JOVIAL  Program.  We  recommend  that 
the  Service  Ada  language  programs  be  strongly  endorsed,  and  that  they  continue 
to  be  receive  adequate  staff  and  funds.  The  various  components  of  this 
Program  should  be  better  coordinated. 
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5 .4  Application  of  Ada*  and  MCF  to  the  WIS  Upgrade 

The  Task  Force  considered  the  potential  for  use  of  current  and  proposed 
standards  for  such  significant  programs  as  the  WWMCCS  Information  System  (WIS) 
upgrade.  Our  assessment  of  the  situation  and  resulting  recommendations 
follow. 


5.4.1  Discussion 

There  is  a  considerable  amount  of  software  running  today  which  supports 
WIS  site  operation  (some  10  to  15  million  lines  of  code)  and  which  will  remain 
in  COBOL  or  FORTRAN  as  the  WIS  is  upgraded  to  new  hardware  and  architecture. 
The  amount  of  new  code  which  will  be  generated  is  estimated  to  be  on  the  order 
of  two  to  three  million  lines  over  the  upgrade  period  from  1983  to  1989.  It 
is  expected  that  commercial  support  will  be  available  in  higher  order 
languages  (COBOL,  FORTRAN  and  Ada)  to  meet  most  WIS  support  needs.  The 
schedules  for  development  of  Phases  I  and  II  of  the  present  upgrade  plan 
precede  the  availability  of  Ada  and  its  support  environment.  The  schedules 
for  Phases  III  and  IV  are  more  compatible  with  Ada  availability  except  for  the 
potential  lack  of  maturity  of  the  language  and  the  completeness  of  the  support 
environment  early  In  these  Phases. 

Each  command  or  agency  may  choose  a  different  set  of  hardware  to  meet  its 
command-unique  requirements  and  its  logistic  support  concerns  as  influenced  by 
the  totality  of  ADP  hardware  and  its  support  needs  (WWMCCS  and  non-WWMCCS)  at 
the  command.  To  support  the  use  of  different  hardware  and  to  aid  future 
transition,  support  software  specifications  should  be  at  the  level  of  general 
capabilities  and  standard  user  Interfaces. 

Inter  system  and  local  network  protocols  should  be  developed  from  the 
existing  DoD  standards  and  emerging  international  standards.  Standards  for 
data  elements  as  well  as  protocols  are  required. 


5.4.2  Findings 

For  reasons  of  economic  necessity  and  technical  practicality,  a  very 
large  base  of  existing  software  must  be  preserved  during  the  upgrade  of  the 
WIS.  An  estimated  two  to  three  million  line?  of  new  code  must  be  added  to  the 
system. 

Although  the  schedules  for  the  earlier  phases  of  the  WIS  upgrade  precede 
the  availability  of  Ada  for  operational  or  applications  code,  it  is  not  at  all 
too  early  to  use  Ada  as  a  Program  Design  Language. 


5.4.3  Recommendations 

We  recommend  that  the  Joint  Program  Manager  for  WIS  adopt  Ada  into  the 
WIS  language  family  as  soon  as  reasonable  language  stability  and  support 
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environment  maturity  are  assured.  Our  current  estimate  is  that  this  will 
occur  in  the  1984  to  1985  time  period. 

We  strongly  recommend  that  the  JPM  use  Ada  as  a  Program  Design  Language 
now.  The  structure  and  discipline  could  be  quite  important  to  a  program  as 
large  and  complex  as  WIS.  Further,  it  could  facilitate  the  use  of  Ada  as  a 
programming  language  at  the  earliest  opportunity. 


5.4.4  Additional  Observations 

During  our  brief  review  of  the  planned  WIS  upgrade  we  made  some 
additional  observations  which  may  be  of  both  specific  and  general  value: 


1.  The  limited  amount  of  skilled  resources  which  may  be  available  to 
carry  off  the  upgrade  may  dictate  a  more  conservative  approach  to 
changeover  which  relies  more  heavily  on  emulation  or  plug 
compatibility. 

2.  The  amount  of  readily  available  support  software  may  not  cover  as 
many  WIS  needs  as  expected.  Some,  greater  investment  in  support 
software  may  be  required  to  provide  necessary  capabilities. 

3.  A  greater  investment  to  speed  Ada  maturity  and  applicability  for 
WIS  may  be  desirable. 

4.  The  level  of  standardization  throughout  WIS  should  be  at  the  level 
of  user-visible  functions  rather  than  at  the  machine  or  language 
level  to  aid  transition,  reduce  development  costs  and  reduce 
personnel  needs. 

5.  Approaches  to  multilevel  security  should  be  conservative  and  rely 
on  equipment  separation,  contingencies  to  back  up  new  development 
short  falls,  and  manual  and  physical  controls  as  necessary  to 
handle  critical  multilevel  security.  NSA  developments  may  provide 
some  new  approaches  in  the  next  few  years. 

6.  Instruction  Set  Architecture.  (ISA)  standardization,  as  support 
environments  mature,  may  become  attractive  as  a  mechanism  to  ease 
future  transitions.  This  likelihood  would  be  enhanced  for  WIS  by 
emphasis  on; 


-  Development  of  the  upper  end  of  the  MCF  product  line; 

-  Development  of  large-scale  peripheral  devices; 

-  Development  of  a  full  repertoire  of  system  support  software, 
including  protocols,  storage  management  and  support  for  user 
Interfaces. 


5.5  On  the  Implementation  of  DoD  Directive  5000.29 


5.5.1  Discussion 

DoD  Directive  5000.29,  Management  of  Computer  Resources  in  Major 
Systems,*  covers  two  primary  topics: 

1.  The  nature  and  organizational  structure  of  DoD's  Embedded  Computer 
System  (ECS)  oversight  process.  This  topic  is  covered  in  Section 
5.6  of  this  report. 

2.  Guidelines  for  the  ECS  acquisition  and  life-cycle  management 
process  within  DoD.  This  topic  is  covered  in  this  Section. 


Overall,  the  Task  Force  found  that  the  ECS  acquisition  and  life-cycle 
management  guidelines  are  well-formulated  and  realistic.  They  have  done  a 
great  deal  to  ameliorate  DoD  problems  in  the  ECS  area.  However,  a  good  many 
DOD  programs  still  encounter  significant  ECS  problems.  The  task  Force's 
assessment  is  that  these  problems  have  the  following  primary  causes: 


1  .  Lack  of  application  of  the  existing  guidelines  within  DoD  Directive 
5000.29.  The  Task  Force's  recommendations  to  cover  this  problem 
are  contained  in  Section  5.6  on  the  DoD  Oversight  process. 

2.  Insufficient  ECS  concept  validation  and  commitment  to  fixed  ECS 
solutions  and  budgets  before  the  system's  ECS  requirements  are  well 
understood. 

3.  Conflicting,  confusing  and  over  constraining  ECS  acquisition 
standards. 

4.  Software  program  details,  costs  and  schedules  frequently  are  not 
obliged  in  enough  detail  to  be  a  basis  for  contractor  selection. 
Rather,  these  software  plans  are  often  formulated  only  several 
months  after  contract  award.  This  practice  results  in  a  deemphasis 
on  software  adequacy  in  contractor  selection.  Also,  since  funds 
are  by  then  fixed,  adequate  software  plans  are  frequently  scaled 
back  to  meet  funds  available. 
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In  the  area  of  ECS  concept  validation,  the  Task  Force  found  that  a  number 
of  recent  DoD  programs  had  been  able  to  clarify  ECS  requirements  and  reduce 
program  risk  significantly  through  the  use  of  prototyping  and  competitive 
concept  definition  contracts.  Use  of  these  approaches  was  also  strongly 
recommended  in  the  ASD(C3I)  study3^. 

In  the  area  of  ECS  acquisition  standards,  a  good  deal  of  progress  has 
been  made  by  the  Joint  Logistics  Commanders  toward  a  consistent,  up-to-date 
DoD-wide  set  of  standards.  However,  the  JLC  activity's  progress  is  hampered 
by  its  lack  of  funding  and  its  heavy  reliance  on  volunteer  effort.  The  Task 
Force  believes  that  standardization  activity  needs  to  be  emphasized  and 
provided  with  appropriate  resources  to  do  so.  This  would  not  be  a  large 
burden. 


34Final  Report  of  the  Software  Acquisition  and  Development  Working  Group, 
July,  1980. 
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5.5.2  Recommendations 

The  following  specific  recommended  additions  to  DoD  Directive  5000.29 
would  cover  the  ECS  concept  validation  and  acquisition  standards  problems: 

1.  Paragraph  D.3(g):  "Prototyping  and  competitive  concept  definition 
contracts  shall  be  major  considerations  in  the  acquisition 
process . " 

2.  Paragraph  D.lls  "A  consistent  set  of  DoD-wide  ECS  acquisition 
specifications  and  standards  shall  be  developed,  emphasizing  life- 
cycle  planning,  life-cycle  supportability  and  recognition  of 
hardware-software  differences." 


Some  additional  recommendations  of  the  nature  and  development  of  the 
standards  are: 


1 .  Standards  should  specify  functional  objectives  rather  than 
development  practices  (e.g.,  "ensure  configuration  identification, 
control  and  status  accounting  by  routine,  version  and  release" 
rather  than  "use  a  program  Support  Library  with  the  following  Job 
Control  language  statements"). 

2.  Standards  should  recognize  the  differences  between  hardware  and 
software  development  (e.g.,  the  differing  role  and  nature  of 
Critical  Design  Reviews). 

3.  Standards  should  provide  for  tailoring  in  situations  where  it  is 
cost-effective  (e.g.,  tailoring  deliverable  documentation 
requirements  to  planned  support  needs). 

4.  Responsibility  for  the  standards  effort  should  reside  within  OSD. 
Steps  have  recently  been  taken  to  improve  this  situation35  The  Task 
Force  believes  this  is  an  important  and  necessary  first  step. 

5.  The  defense  acquisition  process  should  reemphasize  and  monitor  the 
incorporation  of  detailed  software  plans  in  system  contractor 
selections. 


35 


Embedded  Computer  Resources  S tandardization  Area  Plan, 


draft  dated  October 


5.6.1  Discussion 


Much  senior  management,  and  not  only  within  the  Department  of  Defense,  is 
clearly  not,  comfortable  about  computers  —  they  are  especially  uncomfortable 
with  software  and  its  inherent  problems.  There  is  not  a  consistent  approach 
across  the  OSD  staff  to  the  issues  of  automation.  This  may  be  due,  in  part, 
to  the  way  the  technology  has  been  exploding  and  to  the  difficulty  of  hiring 
and  retaining  knowledgeable  personnel  in  the  face  of  the  private  sector  demand 
for  the  same  scarce  personnel  resources. 

OSD  has  attempted  to  manage  this  ever-growing  portion  of  its  business 
through  an  ad  hoc  committee  approach.  The  magnitude  of  the  complex  and 
interrelated  issues  to  be  resolved  in  this  area  have  clearly  outgrown  this 
approach.  We  feel  it  is  time  to  recognize  the  need  for  a  meaningful  approach 
which  places  responsibility  in  a  line  function. 

During  our  deliberations,  we  came  to  the  conclusion  that  a  specific 
designation  of  the  Under  Secretary  of  Defense,  Research  and  Engineering  as 
Senior  Policy  Official  for  activities  covered  by  the  provisions  of  Section  908 
of  the  FY1982  Defense  Authorization  Act,  i.e.,  computer  acquisitions  “exempt" 
from  the  Brooks  Act  would  be  desirable.  Further,  we  believe  he  must  have  the 
clear  decision  authority  as  to  which  process  should  be  followed  in  any  given 
case.  That  designation  has  been  accomplished'1  . 


5.6.2  Findings 

We  believe  that  the  Importance  of  computers,  or  perhaps  better  put,  the 
use  of  computers,  has  outgrown  the  committee  management  approach  still  being 
used  at  the  OSD  level. 


OSD  management  and  oversight  is  not  at  a  high  enough  level  to  clearly 
signal  the  appropriate  level  of  management  concern  to  the  Components  and  to 
assure  the  Congress  and  the  Oversight  Agencies  that  DoD  has  adequate  control. 

Programs  of  DoD-wide  importance  being  conducted  within  the  Components 
lack  sufficient  coordination  at  the  OSD  level  to  assure  Joint  use  of  the 
results  and  products. 


^Deputy  Secretary  of  Defense  Memorandum,  Acquisition  of  Automatic  Data 
Processing  (ADP)  Equipment  end  Services ,  February  1 ,  1982 . 


Page  55 


5.6.3  Recommendations 

The  USDRE  has  been  designated  the  Senior  Policy  Official  for  activities 
covered  by  P.L.  97-86  and  since  he  has  the  responsibility  for  the  Tech  Base, 
he  should  develop  an  organizational  approach  which  best  meets  the  needs  we  and 
others  have  identified. 
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5.7  On  the  Implementation  of  P.L.  97-86 

Section  908  of  Public  Law  97-86,  the  FY1982  Defense  Authorization  Act, 
provides  an  opportunity  for  DOD  to  acquire  and  manage  the  computer  resources 
needed  in  defense  systems  both  more  efficiently  and  more  effectively.  At  the 
same  time,  DoD  must  avoid  serious  management  mistakes  which  would  inevitably 
result  in  the  reimposition  of  onerous  controls.  This  discussion  is  intended 
to  provide  a  framework  of  concepts  and  terms  within  which  appropriate 
acquisition  or  procurement  decisions  about  computer  resources  can  be  made. 

Of  all  the  computer  resources  within  a  given  defense  system,  some  will  be 
mission-critical  in  the  sense  that  successful  performance  of  the  intended 
mission  will  depend  upon  them  daily.  All  mission-critical  resources  will  be 
embedded  in  the  sense  that  they  are  considered  within  the  “boundary"  of  the 
system  and  Immersed  in  its  proper  operational  functioning.  Of  these,  some 
will  be  directly  Involved  operationally  in  the  system  mission-operational ,  but 
others  will  be  mission-support  in  terms  of  providing  (say)  specialized  forward 
or  base- level  maintenance  and  logistics.  There  may  be  other  non-embedded 
computers  which  are  also  mission-support  in  the  sense  that  they  are  concerned 
primarily  with  a  given  mission  for  (say)  supply  or  rear-area  maintenance. 
Outside  every  system  will  be  a  variety  of  general  support  systems  providing 
standard  logistical  functions,  financial  management,  personnel  records  and 
movement,  etc. 

The  computer  resources  for  general  support  are  likely  to  be 
commercial-soft  machines  —  soft  in  the  sense  that  they  have  been  designed  for 
Installation  and  use  in  fixed,  well-controlled  physical  environments  and 
intended  for  general  marketing  by  their  vendors.  The  mission-support 
computers  might  well  be  commercial-soft,  for  example  minicomputers 
Incorporated  in  fixed-site,  rear-echelon  automatic  test  equipment,  but  they 
might  also  be  commercial-military  machines  —  ones  which  are  militarized 
versions  of  soft  designs  or  are  especially  designed  ones  for  a  severe  military 
environment.  Examples  would  include  automatic  test  equipment  mounted  in  vans 
or  shipboard,  or  van-mounted  inventory  and  item-issue  systems.  Finally, 
mission-operational  machines  might  be  either  commercial-soft  (e.g.,  installed 
in  forward-area  vans  or  in  aircraft)  or  they  might  be 

mission-specially-designed  for  a  very  particular  purpose  (e.g.,  a  guidance 
computer  in  a  missile).  Not  every  system  can  be  expected  to  have  every 
category  of  computer  resource,  but  the  construct  must  allow  for  all 
possibilities. 

The  DoD  has  several  options  for  obtaining  computer  resources: 

1.  Via  the  established  procedures  Implementing  Public  Law  89-306,  the 
Brooks  Act,  and  heretofore  referenced  for  data  automation 
applications  or  as  ADP  resources; 

2.  Via  the  usual  systems  acquisition  process  in  which  prime,  sub-  or 
associate  contractors  make  the  decisions;  or 

3.  Via  procedures  yet  to  be  established  which  are  wholly  within  the 
DoD  and  are  in  the  spirit  of  the  system  acquisition  process,  but 
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would  use  the  machine-selection  methodology  of  data  automation 
applications ,  but  probably  modified  to  acknowledge  a  mission- 
critical  status. 

A  senior  DoD  official  should  be  responsible  for  determining  in  each 
defense  system  (probably  above  some  size  threshold): 


1.  The  boundary  of  the  system  to  define  what  mission-critical  computer 
resources  are  part  of  the  system. 

2.  The  interfaces  between  the  system  and  other  general  support 
systems,  and  the  support  expected  from  the  latter. 

3.  The  status  of  each  computer  system  within  the  boundary 
—  mission-support  or  mission-operational. 

4.  The  appropriate  means  for  obtaining  each  of  the  computer  hardware 
and  software  resources. 


Historically,  some  senior  DoD  official  was  thought  of  in  a  weapon-system 
context;  but,  given  the  proliferation  of  computers  within  systems  which  are 
not  directly  connected  with  weapons  per  se  plus  the  responsibility  now  implied 
by  P.L.  97-86,  it  would  seem  desirable  that  he  should  become  the  "senior 
official  for  defense  systems." 

In  his  deliberations  about  the  computer  resources  of  a  given  system,  he 
would  have  to  consider  such  collateral  aspects  as: 


-  Operational  vs.  support 

-  Mission-critical  vs.  mission-support 

-  Mission-support  vs.  general  support 

-  Field  vs.  Depot  maintenance 

-  Specialized  vs.  general  logistic  support 

-  Life-cycle  support  of  software 

-  Forward  vs.  rear-area  software  support 

He  would  also  have  the  opportunity  to  identify  other  kinds  of  resources 
—  not  presently  regarded  as  computer  resources  but  which  really  are  —  such 
as: 


-  Specialized  personnel 

-  Software  development  facilities  for  life-cycle  support 
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-  Other  special  facilities  such  as  for  forward-area  hardware 
maintenance 

-  Specialized  training  requirements 

These  considerations  are  shown  in  Figure  5-1.  The  intent  of  the 
framework  and  procedure  outlined  above  is  two-fold: 


Figure  5-1:  Acquisition  Decision  Tree 


1.  To  provide  a  mechanism  for  deciding  between  P.L.  89-306  and  P.L. 

97-86  procedures  for  computer  resources  needed  in  each  system. 

2.  To  assure  adequate  front-end  planning  for  all  computer-resource 
aspects  of  defense  systems. 

There  are  a  variety  of  possible  implementations  on  which  the  Task  Force 
does  not  take  a  position: 


1.  The  Senior  DoD  Official  could  exercise  the  authority  himself  and, 
with  his  staff,  issue  the  appropriate  direction; 


Page  59 


2.  He  could  delegate,  wholly  or  in  part,  to  corresponding  officials  in 
the  Military  Departments  or  Defense  Agencies  for  all  decisions;  or 

3.  He  could  require  the  Component  advocating  a  given  system  to 
incorporate  appropriate  recommendations  in  its  planning  documents 
for  his  review. 


Since  commercial-soft  computers  can  function  as  either  an  embedded  or 
non-embedded  mission-support  role,  it  is  important  to  note  that  the  general 
process  described  above  allows  for  obtaining  them  by  whatever  procedures  are 
best  for  a  given  application  in  a  given  system. 


This  can  mean  that  the  same  model  computer  —  and  perhaps  even  precisely 
the  same  configuration  —  could  for  one  system  be  acquired  under  one  set  of 
procedures  but  for  another  system,  under  the  other  procedures. 
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Appendix  A.  TERMS  OF  REFERENCE 
THE  UNDER  SECRETARY  OF  DEFENSE 


WASHINGTON  DC  20301 
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RESEARCH  AND 
ENGINEERING 


20  August  1981 


MEMORANDUM  FOR  THE  CHAIRMAN,  DEFENSE  SCIENCE  BOARD 

SUBJECT:  Defense  Science  Board  Task  Force  on  Embedded  Computer 
Resources  (ECR)  Acquisition  and  Management 


You  are  requested  to  organize  and  convene  a  Defense  Science  Board  (DSB) 

Task  Force  to  review,  evaluate  and  make  recommendations  concerning  the 
acquisition,  management  and  utilization  of  digital  computers  and  associated 
technology  to  support  the  military  mission  of  the  Department  of  Defense. 

BACKGROUND 

Practically  every  significant,  modern  defense  system  relies  upon  a  digital 
computation  element  or  subsystem  for  either  its  native  operation,  its  inte¬ 
gration  into  the  tactical,  strategic  or  C3I  environment  or  for  its  support. 

Traditionally,  there  have  been  problems  in  defense  system  software,  at  least 
as  great  as  those  faced  by  the  commercial  sector  in  their  large-scale  computer- 
based  systems.  These  problems  include  schedule  slip,  cost  overrun,  and  lack  of 
acceptable  performance  of  the  delivered  product.  The  lack  of  transportability 
of  software  has  constrained  system  upgrades  based  upon  the  sheer  magnitude  of 
the  sunk  investment. 

DoD  management  policy  for  embedded  computers  is  contained,  principally,  in  DoD 
Directive  5000.29,  "Management  of  Computer  Resources  in  Major  Defense  Systems." 
This  Directive  established  a  Management  Steering  Committee  for  Embedded  Computer 
Resources  (MSC-ECR)  to  improve  the  management  of  computer  resources  in  major 
defense  systems,  and  other  purposes.  Secondary  policy  issuances  include  DoD 
Instruction  5000.31,  "Interim  List  of  DoD  Approved  High  Order  Programming 
Languages  (H0L)"  and  proposed  DoD  Instruction  5000. 5X,  "Instruction  Set 
Architecture  (ISA)  Standardization  Policy  for  Embedded  Computers." 

A  study  was  recently  conducted  under  the  aegis  of  the  Assistant  Secretary  of 
Defense  (C3I)  which  concluded  that  all  facets  of  the  software  development  and 
acquisition  process  need  varying  degrees  of  improvement.  The  Senate  Armed 
Services  Committee  included  Language  in  the  FY1982  Defense  Authorization 
Bill  which  will  clearly  exclude  the  acquisition  of  digital  equipment 
for  intelligence  activities,  cryptologic  activities,  weapons  and  weapon 
systems,  command  and  control  of  military  forces,  and  in  direct  support  of 
systems  for  these  applications  from  Brooks  Act  (P.L.  89-306)  provisions. 

There  is  also  an  extensive  effort  under  the  Joint  Logistics  Commanders'  Joint 
Policy  Coordinating  Group  for  Computer  Resource  Management  (JPCG-CRM)  address¬ 
ing  the  implementation  of  policy  through  specifications,  standards,  and  other 
management  tools.  At  least  four  Industry  associations— NSIA,  ADPA,  AFCEA  and 
EIA — have  ongoing  studies.  This  review  should  provide  recommendations  to  the 
DoD  taking  into  account,  to  the  extent  possible,  all  the  factors  considered 
in  the  other  studies. 
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SPECIFIC  OBJECTIVES 

Critical  questions  which  the  Task  Force  should  address  include: 

1.  Are  the  management  policies  enunciated  in  DoD  Directive  5000.29, 

DoD  Instruction  5000.31  and  proposed  DoD  Instruction  5000. 5x  appropriate 
to  the  present?  If  not,  how  should  they  be  modified  for  the  upcoming 
generation  of  technology?  What  are  the  costs  and  benefits  of  these  policies 
and  to  what  extent  can  they  be  quantified?  Is  the  implementation  of  these 
policies  within  the  DoD  Components  adequate? 

2.  Are  the  key  embedded  computer  programs  of  the  Department — Ada,  NEBULA, 
NECS,  MIL-STD-1750 — properly  constituted  and  supported?  Uhat  changes  can  and 
should  be  made  to  afford  maximum  benefits  to  the  Department  as  a  whole?  To 
what  extent  should  these  programs  and  the  policies  of  1.,  above,  be  considered 
for  near-term  programs  such  as  the  WWMCCS  upgrade? 

3.  Does  the  Management  Steering  Committee  for  Embedded  Computer  Resources 
serve  a  useful  role?  How  could  it  be  improved  or  is  there  a  better  mechanism 

to  provide  oversight  and  policy  guidance?  Are  there  other  organizational  issues 
of  consequence  and,  if  so,  what  recommendations  can  be  advanced  for  improvement? 

A.  Uhat  is  the  effect  of  the  Legislative  and  Regulatory  Environment  upon 
the  ability  of  the  Department  of  Defense  to  make  adequate  use  of  Digital 
Technology?  Consideration  should  be  given  to  Public  Law,  Defense  Acquisition 
Regulations,  Component  regulations,  business  practices  and  appropriate  policies, 
both  central  and  local. 

ORGANIZATION 

The  Task  Force  should  begin  its  work  as  soon  as  possible  and  should  deliver 
a  final  report  not  later  than  January  31,  1982.  Interim  reports  should  be 
submitted  as  issues  are  resolved  to  the  satisfaction  of  the  membership. 

This  Task  Force  will  be  sponsored  by  Mr.  Robert  F.  Trimble,  Acting  Deputy  Under 
Secretary  of  Defense  (Acquisition  Management).  Mr.  Thomas  Crowley  has  agreed  to 
serve  as  the  Chairman.  Mr.  H.  Mark  Grove,  Deputy  Director,  Embedded  Computer 
Resources  and  Electronics  Policy,  0USD(R&E)ECR,  will  be  the  Executive  Secretary. 


Page  63 


Appendix  B.  MEMBERSHIP  OF  THE  TASK  FORCE 


Chairman 


Present  Position 


Dr.  Thomas  H.  Crowley 


Executive . Director, 

Computer  Technology  and  Design  Engineering, 
Bell  Laboratories 


Executive  Secretai 


Mr.  H.  Mark  Grove 


Director,  Embedded  Computer  Resources 
OUSDRE 


DSB  Liaison 


Col.  Wayne  B.  Davis,  USA 


Defense  Science  Board,  OUSDRE 


Members 


Dr.  Barry  W.  Boehm 


TRW,  Defense  and  Space  Systems  Group 


Dr.  James  C.  Fletcher 


Mr.  Joseph  M.  Fox 


Dr.  George  H.  Heilmeier 


University  of  Pittsburgh 

Chairman,  Software  Architecture 
and  Engineering 

Vice  President,  Corporate  Research, 

Development  and  Engineering,  Texas  Instruments 


Dr.  Walter  B.  LaBerge 


Assistant  to  the  President 
Lockheed  Missiles  and  Space  Co. 


Dr.  Edith  W.  Martin 


Executive  Director,  Atlanta  Operations 
Control  Data  Corporation 


Mr.  Alan  J.  Roberts 


Vice  President,  Strategic  Systems 
Mitre  Corporation 


Dr.  William  R.  Sutherland  Sutherland,  Sproull  and  Associates 


Dr.  Willis  H.  Ware 


Dr.  John  G.  Weber37 


Corporate  Research  Staff 
The  RAND  Corporation 

TRW,  Military  Electronics  Division 


Now  with  VERAC,  Inc.,  San  Diego,  CA. 
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Military  Observers 

LtGen  Hillman  Dickinson,  USA  Director,  C3  Systems,  OJCS ' 

MGen  Emmett  Paige,  Jr.,  USA  Commanding  General,  U.S.Army 

Electronics  Research  and  Development  Comnand 

RAdm  James  R.  Lewis30,  USN  Deputy  Chief  of  Naval  Material 

MGen  D.  L.  Evans,  USAF  Joint  Program  Manager 

HWMCCS  Information  System 

Assistants  to  the  Task  Force 

Mr.  Owen  C.  Holleran  Headquarters,  Department  of  the  Army 

Mr.  William  R.  Smith  Office  of  the  Assistant  Secretary 

of  the  Navy,  RE&S 

Maj  David  A.  Herrelko,  USAF  Headquarters,  USAF 
LCol  John  M.  Selzer,  USAF  OJCS,  C3  Systems 
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Appendix  C.  DEFINITIONS 

The  Instruction  Set  Architecture  (ISA)  of  a  computer  is  the  set  of 
instructions  (e.g.,  add,  store-into-memory )  used  to  program  a  computer, 
augmented  by  other  minimal  information  available  to  a  programmer  (e.g., 
interrupt  capability). 

Each  computer  has  an  ISA  which  is  the  logical  basis  for  its  physical 
structure. 

An  ISA  may  be  implemented  in  many  different  ways  since  its  specification 
is  independent  of  hardware. 

An  alternative  definition  of  Instruction  Set  Architecture  is: 


“An  ISA  is  the  specification  of  the  interface  between  software 
and  hardware.  It  includes  the  attributes  of  a  computer  as  may  be  seen 
by  a  machine  (assembly]  language  programmer  or  the  target  code 
generator  of  a  compiler  for  a  high-order  language  (HOL).  It  describes 
the  conceptual  structure  and  functional  behavior  of  a  computer  as 
distinct  form  the  organization  of  the  data  flow  and  controls,  logic 
design  or  physical  implementation." 

MIL-SPEC  Computers  are  specially  designed  for  the  military  environment. 
The  performance  required  is  delineated,  usually,  in  a  Military  Specification 
(MIL-SPEC)  or  Military  Standard  (MIL-STD )  which  form  an  integral  part  of  the 
contract  for  the  acquisition  of  the  specific  materiel.  MIL-SPEC  equipment  is 
generally  not  available  "off-the-shelf"  and  must  be  designed  and  fabricated 
"to  order"  to  meet  a  set  of  performance  and/or  environmental  requirements, 
including  the  form  factor  of  the  equipment.  Examples  are  space-borne 
equipment;  airborne  weapons-delivery,  navigation  or  flight-control  computers. 


Embedded  Computers  are  those  computers  incorporated  as  an  integral  part 
of,  dedicated  to,  or  required  for  the  direct  support  of,  or  for  the  upgrading 
or  modification  of,  major  or  less-than-ma jor  systems.  Thus  this  term  refers 
not  only  to  those  computing  devices  buried  deeply  within  subsystems  as  radars, 
radios,  missiles  and  the  like  but  more  generally  to  computers  which  are  used 
to  perform  a  portion  of  a  larger  task  such  as  fire-control,  automatic  testing, 
navigation,  and  threat  warning.  The  key  discriminator  is  whether  the 
application  is  computation  alone  or  whether  computation,  is  merely  a  subtask  to 
be  performed  as  a  part  of  a  larger  activity.  In  the  industrial  realm, 
"embedded"  computers  would  be  found  managing  process  control  in  a  steel  mill 
or  a  chemical  plant  or  as  the  automation  element  in  an  automobile.  In  a 
hospital  or  research  laboratory,  computers  are  embedded  in  CAT  scanners,  in 
scintillation  counters,  in  gas  chromatographs,  in  EKG  or  EEG  equipment  —  they 
perform  specialized  and  dedicated  tasks  and  are  not,  in  general,  available  to 
support  the  general  computational  or  data  processing  needs  of  the  organization 
and  hence  are  subject  to  a  more  specialized  selection  process  than  classical 
Automatic  Data  Processing  Equipment  (ADPE). 
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Embedded  Computer  Resources  include  the  totality  or  resoar cea  required 
for  the  support  and  operation  of  "embedded  computers Thus,  the  tern 
includes,  but  is  not  necessarily  limited  to: 


-  Computer  Data 

-  Computer  Hardware 

-  Computer  Programs 

-  Documentation 

-  Personnel 

-  Supplies 

-  Services 

-  Training 

-  Software 


*  Support  Software 

*  Utility  Programs 

*  Test  Software 

*  Operational  (Applications)  Software 

*  Training  Software 


Tactical  Computers  are  those  used  in  the  tactical,  strategic, 
intelligence,  cryptologic  or  command  and  control  environments  of  military 
operations.  Generally  this  would  mean  deployed  equipment  on  ships,  aircraft 
or  with  the  fielded  army  or  dedicated  to  the  training  and  support  of  military 
personnel  as  a  part  of  their  military  assignments  as  contrasted  to  the  CONUS 
administrative  support  of  the  Department,  the  Services  or  the  Agencies.  The 
term  is  even  less  precise  than  "embedded"  and,  so,  we  prefer  not  to  use  it. 

Ruggedized  Computers  are  those  which  are  specially  designed  and  tested  to 
ensure  resistance  to  such  environmental  hazards  as  shock,  vibration,  humidity, 
sand,  salt,  temperature,  operational  and  storage  extremes,  altitude  and 
explosive  hazards  without  the  requirement  for  redesign  or  change  of  the 
computer  itself.  That  is  the  protection  is  provided  through  shock  mounting, 
enclosures  such  as  transit  cases,  or  other  means  to  isolate  a  fundamentally 
commercial  instrument  from  an  environment  it  was  not  basically  designed  and 
produced  to  withstand.  Some  consider  that  a  complete  mechanical  redesign 
holding  the  electrical  design  constant  constitutes  "ruggedized"  equipment; 
however  that  would  be  the  extreme  case  and  would  require  different  production 
lines  and  techniques  so  one  is  talking  about  a  completely  separate  product  in 
this  case  and  the  "learning  curve"  is  broken,  support  requires  differing  parts 
and  training,  etc. 

Commercially  Available  Computers  are  those  available  to  the  general 
public  from  the  equivalent  of  a  published  catalog  at  preestablished  prices  and 
requiring  essentially  no  design  effort.  Clearly,  options  may  be  required  and 
adaption  or  configuration  to  the  customers  needs  may  be  required  but  this 
tailoring  should  be  a  small  portion  of  the  final  selling  price.  It  would  also 
be  expected  that  the  equipment  would  be  supported  by  existing  field  service 
personnel  and  commercial  logistics  systems.  This  class  would  generally 
exclude  "ruggedized"  equipment  although  equipment  for  steel  mills,  chemical 
plants  and  petroleum  fields  may  be  both  commercially  available  and  ruggedized. 
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Commercially  available  computers  are  frequently  delivered  with  software  which 
may  have  application  to  common  business,  technical  or  educational  needs. 
Software  associated  with  MIL-SPEC,  MIL-STD  or  special  purpose  computers 
designed  for  tactical,  strategic,  intelligence,  cryptologic  or  command  and 
control  environments  is  generally  unique  to  the  special  military  application. 


Mission  Critical  Computer  Resources  (MCCR )  could  include  all  of  the  above 
categories.  The  test  here  is  the  application  and  whether  it  is  on  the 
critical  path  to  the  fulfillment  of  the  military  mission  of  the  Department, 
either  defensive  or  offensive.  The  test  is  the  application  of  the  equipment 
and  not  its  source.  All  computers  and  related  equipment  destined  for  the 
“excluded"  applications  of  10  U.S.C.  2315  are  included  in  this  general 
description,  i.e.,  "...if  the  function,  operation,  or  use  of  the  equipment  or 
services-- 


1.  "involves  intelligence  activities; 

2.  "involves  cryptologic  activities  related  to  national  security; 

3.  "involves  the  command  and  control  of  military  forces; 

4.  "involves  equipment  that  is  an  integral  part  of  a  weapon  or  weapons 
system;  or 

5.  "...is  critical  to  the  direct  fulfillment  of  military  or 
intelligence  missions.” 

Not  included  in  the  fifth  excluded  application  area  is  equipment  and 
services  "...for  routine  administrative  and  business  applications..."  Interim 
guidelines  for  acquisitions  under  10  U.S.C.  2315  maintain  this  gray  area  under 
case-by-case  oversight  to  assure  that  the  legislative  intent  is  preserved. 

The  definition  will  be  modified  as  we  gain  experience  in  this  area. 


Computers  in  Direct  Support  of  Mission  Critical  Computer  Resources  may 
include  all  of  the  above  described  categories.  More  particularly,  they  are 
those  computers  which  remain  under  exemption  five  when  the  ..."routine 
administrative  and  business  applications  including  payroll,  finance, 
logistics,  and  personnel  management  applications)"  are  excised.  There  are 
systems  in  these  applications  areas  which  fail  the  "routine"  test  as  they  are 
on  the  critical  path  toward  the  fulfillment  of  the  "military  mission." 
Automatic  test  equipment,  deployable  logistics  systems  such  as  the  Combat 
Support  System,  NALCOMIS,  Global  Weather  Service  systems,  the  Satellite 
Control  System,  the  NORAD  system.  Avionics  Intermediate  Shop  equipment,  and 
shipboard  machinery  monitoring  systems  are  examples  of  this  area  of 
application. 


